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SECURE MULTI-ENTITY ACCESS TO RESOURCES ON MOBILE 
TELEPHONES 

* 

m 

FIELD OF THE INVENTION 

5 

The present invention relates to a method for providing secure multi-entity access to 
resources on a mobile telephone, such as a smartphones, or other kind of voice and data- 
enabled mobile device. 

DESCRIPTION OF THE PRIOR ART 

■ ■ 

Smartphones are an emerging class of mobile device that combine mobile voice and data 
features into a phone-style device together with an operating system that enables new 
software applications to be installed and run. Current popular smartphone operating 
systems are Symbian OS, Smartphone 2003 and PalmOS. Operating systems are 
currendy designed as single-user operating systems so are optimized for use by a single 
user. Further, the mobile industry in general considers that a hierarchical *onion skin' 
model defining resource access is an adequate picture of mobile device security: 

I 

Inside level: User, phone owner 

Next level: Operating system / middleware software vendor 
Next level: Handset manufacturer 
Outside level: Network Operator 

25 This picture means that, for example, if an end-user runs a banking application from 
Bank A which stores personal information and also information belonging to Bank A 
(such as access codes to connect to their systems) then that data is accessible to the end- 
user, but also everyone in layers of the model that are outside of the inside level If the 
netvi^otk operator wants to, it can access all of the end-users data. It also means that if an 

30 entity such as a software vendor is trying to sell this device to an i&nterprise, for them to 
roll out some company critical system, then the enterprise is forced to either buy into the 
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picture that handset manufacturer and network operators ultimately control that 
application and its data, or not roll out the a.pplication. 

From another angle, consider the mobile telephone as a networked computer. There are 
5 millions of users out there in cyberspace who are potentially able to connect to 
applications running on that phone. With the *onion skin* model, there is no grounding 
provided, no operating system support, no advice given for an application rvmning in the 
context of multiple incoming connections. How does a telephone decide that user A can 
do X but user B cannot? Simply put, it must decide itself — each application is on it's 
10 own. If the application vendor fails to address the problem, then user B in cyberspace 
can theoretically nan code on the telephone with the same level of privilege as the phone 
owner — since there is only one onion skin layer that it can operate in. 

The upshot of these two factors is (a) organisations will not adopt smartphones since 
15 there is no adequate security model, (b) applications do not get written because there is 
no security support, or (c) end users are scared away from using smartphones after high 
publicity secvirity scares about Jost data or illegitimate use of their phone. Or all three. 

■ m 

* 

20 

What is needed is a security model that reflects both the needs of the enterprise, 
application developers and end users. 
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SUMMARY OF THE INVENTION 

Ina first aspect, there is a method of controlling access to a specific resource on a mobile 
5 telephone; comprising the steps of: 

(a) associating an identity v/ith a permission state, in which an identity is a label 
applicable to one of several entities on whose behalf the resource covild potentially be 
used and the permission state defines whether or not the resource can actually be used; 
and 

10 (b) allowing use of the resource solely to an entity or entities labelled with an identity 
associated with a permission state that does pejniiit such use. 

Although' conceptually similar approaches to access control have been used in the 
networked PC space, to date no-one has applied this approach to mobile telephones. 
15 The reason is that there is an overwhelming assumption that mobile telephones are single 
user devices; consequentiy, a skilled implementer working in the mobile telephone area 
would not normally look at access control teclnniques deployed to enable multipk entities 
to access resoxirces on a device — e.g. to enable different end-users to access data or 
applications on a single PC or server. 

20 

The present invention therefore reflects the situation that diere are multiple 'entities' at 
work within the telephone. It starts witii the fiandamental concept of an Identity* — a way 
of referring to a person, a user, an organisation, a piece of code, a server etc — an entity 
on whose behalf some code is run on the device. Different entities can share an identity, 

25 but can also have different identities. Hence, because there are multiple entities at work, 
multiple identities can also be at work in a smartphone containing a number of 
applications - the different identities associated with different entities such as phone 
owner, the operator, the application vendor, the IS manager of the company the owner 
works for etc. Hence, unlike pnor art approaches diat assume the mobile telephone is a * 

30 single user device, the present invention embraces the idea that multiple entities and hence 
multiple identities are at work and allows tke phone to be configured such that each 
identity has a set of permissions that indicate -what it is allowed or not allowed to do. 
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In an implementation, the method comprises: 

(a) a script or other kind of executable code associated with a given entity sending a 
request to use the specific resource; the script being labelled with an identity or including 
a secure signature ficom which an identity can be deduced; 

(b) a software component running on the device processing the request and using 
the identity to determine the applicable permission state associated with the identity for 
that script or executable code. 

The permission state typically includes a penrussion type and a value; the permission 
state associated with a given identity can be updated or altered, for example on 
instructions sent from a computer remote from the mobile telephone. 

The term *use' of the resource includes one or more of: access, deployment, alteration or 
deletion. 

The script or otiaer kind of executable code associated with a given entity may be labeEed 
with an addifiona/ idcanty separate ficom or independent of the identity of the given entity; 
the additional label identifying the script or code. Traditional security systems like UNIX 
access control have permissions and a list of users. In UNIX, each process has 3 
identities - the owner of the executable, the effective id of the person who is running it,, 
and a saved id for processes that have temporarily switched to some other id. But with 
tliis feature of die present invention, when a sciipt/piece of code asks for a permission, 2 
identities are presented - the effective id of the person who is running it, and tie id of that 
piece of code. So the code itself has an identity independent of who owns it or runs it. The 
software component can tiien use the permission state associated with this additional 

* 

identity to enable it to determine if the script/code itself is permitted to use the resource, 
irrespective of whedier the given entity is allow^ed to use the resource. 

The script or code can have its identity altered, with the alteration being a result of 
instructions sent to the telephone from a remote computer. The identity can be altered 
to an identity associated with a higher or broader permission state only if the script or 
code has been autiienticated to a pre-defined confidence level. 
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5 

The method can be deployed on the mobile telephone by a component that is not p3Xt of 
the operating system and can therefore be installed onto the telephone without needing 
to be burnt into the main ROM of the telephone d:iat stores the operating sjrstem. This 
is especially useful as it enables the method to be deployed on mobile telephones that 
5 have already shipped. 

For optimal security, the component can run in the secure SIM of the mobile telephone. 
Alternatively, the permission states and their association with different identities can be 
stored in the SIM, with the component running outside tlxe SIM. This provides a much 
10 greater level of security than is possible using just software because a SIM-card hardware 
token, combined with strong encryption, provides a strong level of authentication. 
Remote administration of the permission states associated with different identities is 
possible by sending instructions from a computer remote from the computer. • 

15 The component stores in memory, or accesses from memory a list of the permission 
states associated with different identities. Further, an identity is determined for any 
script that seeks to access code by an authentication process using a digital signature. 
The authentication process generates an identity handle that can be transferred as a 
token; the identity handle has an associated confidence level based on the authentication. 

20 

The entity can be any of : an individual end-user; a network operator, a mobile telephone 
manufacturer; an application developer or vendor; an employer, an operation. Where the 
entity is an operation, the operation can be booting the telephone so that startup code is 
run, the startup code having a specific identity, and the permissions for this identity 
25 determine what can or cannot be done at startup. Anothier operation could be a timer 
going off. 

Also, the entity can be a kind or type of entity. 

30 The approach of the present invention is very different from the conventional 'onion 
skin' hierarchical model Instead, at least two entities do not have identities that are 
* associated witii permission states that are hierarchically arranged witii respect to each 
other. In many instances, no entities have identities (hat ate associated with permission 
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States that are hierarchically arranged with respect to each other and no entity 
automatically has rights to use all resources on. the telephone. 

The resource can be specific data; die permission state can then determine whether die 
5 data can be read, modified or deleted. The resource could instead be a specific executable 
application and the permission state then determines whether the application can be run 
or updated. The resovurce could also be a hardware resoxirce on the telephone, such as a 
networking or communications resource on die telephone. 

10 In terms of physical interactions witii hardware, the step of associating an identity widi a 
permission state results in a record of the association stored in a memory of the 
telephone. Also, the step of allowing use of the resource takes place by a CPU in die 
telephone processing data. 

15 In another aspect, there is a mobile telephpne with specific resources, in which access to 
die resoxirces is controlled using the mediod defined above. 

Concept level examples 

20 

Some examples will assist. Consider a file on the phone containing bank account details. 
The phone owner runs the banking application which tries to access that data — there are 
two identities at work there — the owner, and die banking application. Access control is 
handled by a software component, namely a kernel that is not an integral part of the 
25 operating system; this is the *mrix kernel'. It can decide that the owner is allowed read 
only access to die data and diat, furthermore, die banking application can also access the 
data (contrast this with the Space Invaders game an user just downloaded — that most 
certainly cannot access the banking data — no matter who runs it). 

30 Digital signatures can be used to ascertain that die banking application is what it says it is 
— i.e. it is not the invaders game in disguise. Now consider Bank A — they want to 
• remotely administrate the banking applications diat are rolled out — maybe to change 
some of the data. They connect to the phone and log in to the banking application 
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administration module. The 'mrix' kernel can decide that the bajik owns the bank 
account details and can tiherefore have read/write access to the file. 

As a further example consider now that the user goes to work for Company B as a 
5 salesman, and they roll out the Company B sales application onto the user's phone. 
There are now multiple applications on the phone, multiple sources of data, and multiple 
owners. The user has his own personal contacts, Company B contacts, Bank A account 
information and Company B sales figures. No one organisation should have access to all 
of that. The present invention makes sure that everyone just; has access to the 
10 information that they should. 

A more complex example follows: User Bob gets a banking application from Alice Bank 
Ltd. The banking application is stored on his phone and uses m-Network. It consists of 
two scripts, mrBankClicnt and mrBankAdmin. A note on terminology here: an 
15 implementation of the present invention deploys "pipe processors'*. These are small 
stand-alone modules written in C++ or scnpting languages that eixcapsulate a range of 
smartphone functionality. Device resident mtix pipe processors are prefixed with "mr**. 

Bob can run mrBankClient to access his bank account details, view liis statements, make 
20 payments etc. Alice Bank can remotely run mrBankAdmin to administrate his accoimt, 
e.g. allow new banking functions, or remove him if he leaves tiie bank. When the 
banking application was provisioned to Bob's phone all the necessary identity and 
permission settings were also provisioned into the kernel's identity database (currentiy a 
text file called identity.ini). Here are some examples to illustrate how the system works: 

25 

Bob runs the mrBankClient script which pops up a simple user interface. By default this 

« 

is running as a Guest identity. If Bob tries to access bankirrg information then 
mrBankClient will ask the kernel - is Identity Guest allowed to access bank account data? 
The kernel wiU check and reply with the answer NO. 

30 

Bob chooses the Logon method in the UI, and is asked to state which identity he is, and 
to present credentials to back that up. This could be a usemame and password 
combination. It could be a biometric indicator such as a fingerprint (identity and 
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credentials in one). The identity and ctedendals may also just be assumed - this is Bob's 
phone, and the Bank/Bob trusts that Bob does not lend his phone to anyone else, and if 
it is stolen dien it will be locked Whatever method die mrBankClient script wiU ask the 
kernel to set the current identity to •Bobldentity' with the credentials. The kernel looks 
5 up in the identity database and decides whether or not to grant permission. The current 
identity running the script has now switched from Guest to Bobldentity. 

Bob now tries to view his statement The mrBankClient asks the kernel if Bobldentity is 
allowed to view statements. The answer is yes and Bob looks at htis statement. 

10 

Alice Bank decide to give Bob an overdraft. This means that the mrBankClient script will 
be able to make payments even when Bob's balance has got to zero - cvurrendy the 
permission 'OverdraftLimit* for Bobldentity is set to zero. Using a terminal at the bank, 
an employee of Alice Bank connects to to mrBankAdmin service on Bob's phone which 

15 causes the mrBankAdmin script to be run. The bank employee presents credentials to 
mrBankAdmin - probably a username and password again, so now the mrBankAdmin 
script is running as identity AliceBankldentity. Alice Banks chooses the 'add overdraft' 
option. The mrBankAdmin script now needs to update permissions for Bobldentity. So 
mrBankAdmin asks the kernel to change the OverdraftEimit permission for user 

20 Bobldentity from 0 to 500. When it does this it passes in the identity of the current user - 
AliceBankldentity - and also it's own identity mrBankAdminldentity. The authenticity of 
mrBankldentity is assured by the fact that the mrBankAdmin script is signed with a 
signature that corresponds to mrBankAdminldentity. The kernel must now decide 
whether the request is allowed. It looks up first in the identity database to ask 'Does the 

25 AliceBankAdminidentity have permission to alter the permissions of Bobldentity?' 
secondly it will ask the same question of mrBankAdminldentity - i.e. is that script 
allowed to do that, irrespective of who is running it? All is well since the required 
permissions have been set in advance and the overdraft is grarLted and Bob can go on a 
spending spree. 

30 

Finally - Betty secretiy accesses Bob's phone and alters mrBankClient script maliciously 
so that running it will execute a viral program when the phone is booted. Bob does not 
realise and runs the altered mrBankClient script as normal. Betty's code is executed 
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which requests to use mrEvent to add a new command to the BOOT event- This request 
is run on behalf of Bob since Bob has lo^ed in properly to die application. All is not 
lost however. mrBankCIient script executes mrEvent, so mrEvent checks whether 
Bobldentity and the script identity have permission to change events at boot The scdpt 
identity is not presented as mrBankClientldentity, since die script has been altered and so 
the signature bannot be verified. Instead the script is presented as GuesL Luckily the 
permissions for mrEvent around setting boot events have been set sensibly so that no 
matter who runs die command, it can only succeed if the authenticity of the running 
code can be established - i.e. untampered versions of mrFile, rshd (this is a command 
interpreter module, and is normally set up to start up on boot) or user scripts would 
succeed, but not tampered versions. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

5 The invention will be described with reference to the accompanying drawings, in which: 

1 ... 

Figure 1 is an example configuration of a system ('mrix*) for rapid application, 
development that provides for secme multi-entity access to resources on mobile devices; 

10 

Figure 2 shows a possible mrix architecture for an implementation of th.e present 
invention; 

Figure 3 shows how mrix consists of a number of elements which can be used to nm 
15 commands over local links (IR, Bluetooth and USB) as well as via a remote relay 
(TCP/IP, GPRS); 

Figure 4 shows the class structure of the mrix kernel; 

20 Figure S shows a portion of the Figure 4 class structure; 

Figure 6 shows a matrix of separate policy/permission stores; 
Figure 7 is a class diagram for the MrixKemelTasks.dll; 

25 

Figure 8 shows a class diagram for MrixKemeLdll. 
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DETAILED DESCRIPTION 



A.1 Overview of mrix 

The present invention is implemented using a software called 'mrix' ftom Intuwave 
5 Limited, mrix fecilitates the rapid develop of networked application softwaxe for mobile 
devices and provides for secure multi-entity access to resources on such devices. An 
implementation comprises software resident on the different compiating devices 
connected to the network, including mobile device, such as a smartphone, desktop PC 
and server, wida an example configuration shown in Figure 1. 

10 

Software components are required on all of the different elements in th.e network to 
facilitate rapid application development and deployment. This is illustrated by the 
following example for developing a networked application on the mobile device that 
enables a user to make full use of an enterprise CRM system for better customer 

15 relationships. To do this, software must be developed on the mobile device that can 
connect to an enterprise server, that implements the CRM system and man.ages all of the 
customer interactions for the enterprise. The mobile device must be able to connect 
both over a wide area connection to the server (such as over GPRS) as well as through a 
faster local connection through a broadband wireless link through the PC. The limited 

20 user intetfiice of the mobile device also means that the mobile device must connect easily 
with the desktop PC to allow the user to take advantage of the large screen, and keyboard 
of the desktop PC when the user is sitting at his or her desk. 



The traditional means of developing such an application would be to develop the 
25 software on the desktop PC using appropriate development tools, such as an IDE, and 
to run and test the application on an emulator on the desktop PC, Once the software is 
successfully running on the emulator then it can be transferred to the mobile device, 
where it needs to be debugged again. This approach is often fine for non-networked 
application as there is littie difference between the emulator and PC. However, for 
30 networked applications the emulator does not have the range of network connections 
available on tiie mobile device so development is much more difficult This problem is 
overcome in mrix by having components on the desktop PC (which term includes 
Windows, Macintosh, Linux or any other operating system powered computers) and 
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mobile device that can be executed over the network connection, either locally over a 
local wireless IttiW, such as Bluetooth, or remotely over GPRS (or any other connection 
to the phone such as SMS). Hence, the developer can proceed in a much faster way for 
development of the networked application as follows: 

1. The developer chooses which of the modular set of mrix pipe processor 
components will be used for the applicatipn. 

2. The developer tests how the chosen pipe processors will be used from the 
command line. < 

3. A simple script can be put together to put these together into a complete 
application running on the phone, again running remotely from the desktop PC. 

4. Coimectivity components on the PC, such as mRouter, which may be part of 
mrix, are used if networked connectivity is required to, or routing through, the 
desktop PC from the mobile device. See PCT//GB2002/003923, the contents 
of which are incorporated by reference, for more details on mRouter. 

5. Connectivity components on the server are used if the server needs to connect to 
the phone. This is required as the phone's IP address is not visible to the outside 
wodd so cannot be contacted by the server. Hence, the Relay server is required 
that is visible by both the phone and back-office server, to enable networked 
communication to the server. 

mrix is a wireless software platform designed to significantiy reduce the time to market in 

« 

producing solutions involving smartphones by:- 

• reducing the learning curve and therefore opening up development to a larger 

community of developers 

• providing network OS like facilities allowing smartphones to be treated like 

shared network components 

• providing critical '*building blocks" which encapsulate complex smartphone 

functionality. 

mrix includes a platform agnostic remote command execution environment for 
smarq>hones. A cotimiand interpreter interfaces to a smartphone through a set of 
commands or "pipe processors". These are small, stand-alone modules written in C++ 
or scripting languages diat encapsulate a range of smartphone functionaUty. Device 
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resident mtix pipe processors (prefixed wida "mr'*) are provided which facilitate the 
control and management of multiple bearers (GPRS, SMS, Bluetooth, MMS, WiFi etc); 
device peripherals (such as barcode readers, pens, printers, GPS etc); odier devices and 
servers; and network billing. Pipe processors can be "chained'* together to build more 
5 functionality. These building blocks allow fast and iterative development of mobile 
solutions. The use of scripting languages opens Up development to a much broader 
community of developers. 

mjcix Architecture 

10 mrix is designed around a command interpreter running on a smartphone and a 
command execution shell running on a remote PC or other suitable platform. Pipe 
processors can be invoked remotely (like Unix commands) from a desktop PC via nci- 
Router™ or a remote server via a Relay. This not only allows development and 
debugging of an mrix solution to be carried out from the convenience of a desktop PC 

« « 

15 but also allows smartphone components to be shared at runtime over networks. 

Some pipe processors are mandatory and are considered core to the system. Bxamples 
include mrEvent or mrAt which are used to start and stop processes based on events. -A. 
set of optional pipe processors are also supplied which can be removed from the 
20 runtime, if required, to minimise the memory footprint. Custom pipe processors can also 
be built in C++ or LUA Script and templates are provided for this. 

A.3 mrix Solution Bxamples 



See "mrix Features at a Glance" for more information on components used. 



Monitoring Spare Parts Availability 


Description 


Keeping an accurate inventory of the levels of spare parts carried 

• 

by a field engineer is difficult. By combining low cost Bluetooth 
peripherals such as pen barcode readers with the advanced 
connectivity features of smartphqnes, mrix enables field service 
engineers to keep a tab on van stock levels and automatically 
enqviire if missing stock items can be picked up firom other vans in 
die area. 



I 
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mrix Solution 
• 


mrBluetooth is used to easily manage the connectivity between a 
smartphone and a bluetooth enabled barcode pen. When the 
engineer needs a part, he/she "swipes'* the product barcode 
from a parts catalogue, A persistent inventory of parts is 
maintained on the device using mrStorage. Automatically, the 
smartphone indicates to the engineer the available stock on the 
van. If the part is not available, an SMS is created via mrMessage 
and sent to odier engineer's smartphones. Using mrWatchFile on 
the recipient's smartphones to trigger on receipt of a specific 
SMS message, the inbovind SMS causes an inventory check to be 
cameQ ouu xz uie remote engmecx s piioiic inciicaLcs liiax uic pdxx 
is available on the van, an SMS is automatically sent back to the 
original engineer. On receipt of the SMS, a prompt automatically 
displays on the smartphone (mrPrompt) which informs the 
engineer that the part is available and supplies the phone number 
of the engineer with that part. The process can be further 
enhanced to only inquire of stock availability from engineers 
who are local using mrSim and the current cell-id. 


Components 
Used 


Relay, mrBluetooth, mrStorage, mrMessage, mrWatchfire, 
MrPrompt, mrSim 



Sending an SMS from a PC 


Description 


Entering text messages can be tedious on a small smartphone. 
With mri^ on the device, it is straightforward to build an 
application which would allow text messages to be composed 
from a Bluetooth connected PC and sent via the phone. 



I 
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mnx Solution 


Using m-Router and mrCmd, the smar^hone is connected to 
the PC via Bluetooth. After authentication of the user 
^identities^ a list of contact names and phone numbers is 
retrieved from die phone (mrContacts) and displayed on the PC. 
The user selects one or more contacts on the PC, enters the 
body of the text message and presses "Send SMS". PC 
application calls mrMessage with the data and the text message is 
automatically sent from the phone. 


Components 
Used 


m-Router, mrCmd, Identities, mrContacts, mrMessage 


1 


Remote Smartphone Support 


• 


P-foviflinD' ^iinnoirt to remote smartDhone users can be a 
problem, mrix allows an operator with a remote PC (and 
permission from the end user) to take full control of a 
smartphone connected over a cellular network. 


nitix Solution 

* 


The end user runs a support application on the smartphone 
which automatically connects to a network hosted Relay over die 
cellular network. The operator also connects to die Relay via an 
application on their PC. Once all pa:tties are connected, the 
operator can connect directiy to the smartphone. Using 

* 

mrKeyboard and mrlmage, a real-time moving image of the 
smartphone's screen and a working visual image of the 
smartphone's keypad are displayed on the operator's screen. 
Using mrPrompt, the operator is able to ask the user for 
permission to carry out certain tasks on the device. Using mrPS, 
the operator is able to see a list of the appUcations currentiy 
running on the smartphone. Using mrLaunch and mrShutdown, 
the operator is able to start and stop running processes and 
restart the phone remotely. Using mrSysInfo, the operator is able 
to see information about the smartphone including available 
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• 


memory, storage types etc. All tasks are completed remotely with 
the user involved throughout the operation. 

• 


Components 
Used 


Relay, Identities, mrKeyboard, mrlmage, mrPrompt 



miix Features at a Glance 


Need 


Feature 


Benefit 


PC Connectivity 


m-Router™ 
mrCmd 


Provides IP over serial link; Allows full 
control of device from connected PC over 
Bluetooth, IrDA, cable etc. 


Operation over 
remote connection 
(GPRS, WiFi etc) 


Relay 

* 


Connects devices and server processes over 
firewall protected networks where devices 
are not "visible". Allows device on GPRS 
network to be discovered by other devices 
or services and facilitates "push". 


Security 


Identities 


Users (or services) have to supply 
credentials to access commands on the 
device. 


Data Storage 


Sky Drive (remote) 
mrStorage (local) 


Important data captured at the smartphone 
can be sent to an always available virtual 
storage device on the network or in the 
device. Data stored can be processed at a 
later time. 
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Messaging 


mrMessage 


Easy to monitor and manage the device's 
message centre. 


Event Driven 

Operation 


mrWatchfire, mrAt, 

mrEvent 


^Trigger actioAs when certain situations are 
met. E.g. run script on receipt of specific 
SMS/MMS message. Also schedule 
operations to run at specified times. 

« 


Connectivity 


mrBluetooth, 
mrObex, mrTCP, 
mrThroughput 


Create and manage connections over 
multiple bearers, examine and process data 
sent and received and measure network 
performance. Send files via OBEX. 


Phone Information 


mrSysInfo 


Returns device information including 
available ddves, firee space, format etc. 


Network 
Information 


mrSIM 


Returns network information such as IMEI, 
cxirrent cell-ID, area and Mobile Network 
Operator. 


Remote Control 


mrlmage, 
mrKeyboard 


Allow device screen to be projected to a 

< 

connected PC and the keyboard of the 
smartphone to be controlled remotely. 


File Manipulation 

i 


mrFile 


Easily manipulate the smartphone file 
system. 


Runtime Control 

• 


mrPs, mrMr, 
mrBoot, 
mrShutdown, 
mrLaunch 


Query, start and stop processes on the 
smartphone; start applications automatically 
on boot and shut down a device. 


Data Capture 


mrPrompt 


Capture data firom the user on smartphone 
via pop up dialog box. 


PIM Data Access 


mrContactSy 
mrAgenda 


Full search, add, edit and delete of 

• 

smartphone PIM data including contacts, 
calendar and memos. Possible to manipulate 



* 
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• 


vcards, minivcards, uuids, speed dials, 
groups etc. 


Specifications 


Supported 
Operating Systems 


Sxnartphbne 


Sjrmbian OS v6.1, 7.0, 7.0s 

Microsoft PocketPC Smartphone Bdidon 


Relay, mrCmd 


MacOS X, linux, Windows ME, 2000, XP Home and 
Professional 



A.4 Feature list 

The core mrix system contains a number of elements some of which are deployed on the 
smartphone: 

5 

mtcmd: mrcmd consists of two elements, a command interpreter for smartphones and a 

remote coromand execution shell. The command interpreter currendy runs- on Symbian. 

The remote command execution shell runs on Windows, Mac OS X and Linux. 

m-Router®: Command-line interface to Intuwave's existing m-Router® product which 
10 handles local connection management on Sjrmbian OS smartphones. m-Router® 

operates over Serial, Bluetooth, USB and IrDA bearers. ' 

mrElay: mrElay consists of both a command-line interface to Intuwave's remote relay 

server and the relay server itself. Currendy the relay server can be accessed from the 

smartphone via GPRS or via a WAN proxied through a local m-Router® link. 
15 pipe processors: Pipe processors are small self-contained modules that encapsulate 

smartphone functionality. A small number of pipe processors that manage event 

handling and file access are in the mrix core. 

script engine: A powerful and compact (60k) LUA 5.0 scripting engine is included on 

* 

the smartphone to allow a developer to readily combine pipe processor functionality 
20 direcdy using scripts. Included with the scripting engine are a number of core mrix 
scripts diat powerfully combine existing pipe processor functionality, 
mrix Reference Manual: HTML pages that explains how to use all the existing core 
• pipe processors. There are also instructions on writing new pipe processors as well as m- 
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Router® and mrcmd functionality, documentation and example scripts detailing is 
included. 

We have a range of additional pipe processors that extend the core functionality of tiie • 
5 system. These pipe processors can be readily added to an mrix system to enhance its 
capabilities. 

A.5 Areas of application 

mrix technology is directiy applicable in a wide range of applications where remote 
10 control of a smartphone device is important: 

« 

Testing: mrix enables full automation of system, functional, acceptance, regression and 
interoperability tests. 

PIM applications: mrix enables rapid development of PC Connectivity PIM 
15 applications through scnpt-accessible toolkits. 

Access controL mrix enables secure multi entity access to resources 

A.6 Benefits 

20 mrix offers numerous benefits to smartphone manufacturers and phone network 
operators. 

Speed of development: mrix development is done in rapid iterations by evolving scnpts 
radier than coding against APIs. This significantiy speeds up the development lifecycle. 
25 Cost: Since mrix functionality is scdpt-based, the cost of development as well as the cost 
of maintenance and enhancement of functionality is significantly reduced. 
Cross-platfotm: mrix offers fiill cross-platform support for smartphones. When 
combined with a cross-platform toolkit, server applications can be built to run across 
different PC Operating Systems. 
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B. Security — Principles and Philosophy 

■ 

The security in mrix is modelled around real Ufe. In real Ufe everyone, everytiiing 
operates as an identity. Examining a banking example in more detail is useful in 
5 understanding the way security works in mrix* The names and scenarios are blatantly 
contrived but they serve to illustrate important points. 

Imagine an individual "Alice" (A) enters ^'Bob Bank International" (B) and queues for 
cashier "Charlotte" (C). Alice then pays in or withdraws some cash. This appears a 

10 simple transaction, but an individual "Eve" may and try and steal money from Alice or 
the bank. . Consider the methods Eve might use. They might attempt to impersonate 
Alice and withdraw fund from the bank, or to impersonate Charlotte at a fake bank, or to 
in fact get a job at the bank and as charlotte defraud the bank. There may also be brute 
force attacks where Eve attacks Alice outside die bank, or attempts to hold up the bank 

15 with a gun. 

Consider an analogous scenario where Alice (A) accesses die conta:cts on bobs phone (B) 

» 

and uses mrContacts (C) to add or retrieve contacts. Consider that "Eve" may try and 
view or corrupt the contacts. They may try and impersonate Alice and use bobs phone, 
20 or give Alice a pretend phone so as to get her to enter the contact. They may even try 
and install software on bobs phone that acts as mrContacts and thus can behave 
maliciously. There may also be brute force attacks on Alice or on the physical hardware 
of Bob's phone. 

■ * 

25 While a callous statement, in both cases the physical protection of Alice is her own 
problem and outside die scope of any protection in/of the bank/ phone. Likewise the 
physical protection of tiie bank building/safe and of the phjrsical memory of the phone is 
a problem xinder the realm of die architect of the building/chips. As witii all security and 
all things, diere is no perfect answer and no total security, just degrees of confidence. 

30 
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This leaves us with a few important points common to both examples that we can try to 
address. 

• We want to be able to prove that Alice is who she claims to be 

• We want to ensure that the cashier/mrContacts is trustworthy 

5 • We want to ensure it is the intended bank/ phone and not an imitation 

• We want to ensure that transactions between Alice and the cashier/ mrContacts 
cannot be eavesdropped and later used to commit fraudulent access. 

• We want to ensure that this not to complicated else the bank/phone will not be 
used. 

10 The is also an example where a person who isn't a customer of the bank / phone wants • 
to do something, maybe change some coins or check a public contact. Obviously in this 
case we don't need to authenticate the user, we CANT since we have no prior 
relationship. Also we want to be able to allow the guest to do some things and not 
others. 

15 

With a bank auditing is important, to show when money was deposited or removed and 
to check who authorised/performed the transactions. Likewise on a phone there may be 
a desire to record which operations are performed, when and by whom, for biUing, 
diagnostics, or purely interest. 

20 

Consider for a moment Alice proving who she is. You can just provide her with a pin 
code or a secret password and ask her to quote this each time she is uses the bank or 
phone. This relies on eve not guessing the password or over hearing it. With online 
banking a common solution is to give a longer pin code and to only ask for a subset of 

25 digits. By asking for a different subset each time, eve has to eavesdrop more transactions 
to discover die entire secret Alternatively one could use Alice's signature. But what if eve 
makes a photo copy of the signature? In that care its safer to have Alice sign something 
in front of the cashier and then compare it to a trusted copy. Using public private key 
technology its possible for Alice to encrypt arbitrary data with her secret key and then 

30 give die encrypted data to the phone togedier witii her public key. Since only the public 
key can decrypt die data, the phone can reasonably assume tiiat die encryptor is Alice. By 
generating unique data to encrypt, die phone can ensure eve cannot capture and re-use 
die signed data for her own nefarious schemes. Of course all diis guarantees is diat Alice 
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has the cotresponding private key. The bank then recognizes Alice on repeated visits if 
she uses the same signature each time. In order to prove that this signature corresponds 
to a person in the real world the bank needs some proof of identity such as a driver's 
licence or a passport. Likewise a digital signature allows the phone to know a user is the 
5 same user as 'last time'. In order to link this signature to a teal world identity it needs to 
be supported by a certificate from another trusted entry. Such a scheme has to rely on at 
least one trusted root entry. 

How does Alice know she can trust the cashier? Firsdy she has to trust that the bank is 

10 careful as to who it employs and gives access to its resources. Alice has to trust that the 
bank checks each moming that charlotte the cashier is who she claims to be. Alice knows 
that most bank systems don't let charlotte see all of Alice's secrets. Charlotte sits at a 
terminal that may display questions to ask Alice, and charlotte may enter the answers, but 
typically charlotte will not see all the secrets, just the subset used to authenticate Alice. 

15 This means charlotte doesn't need to be an expert in authentication she just needs to ask 
the questions on behalf of the banking systems and to enter Alice's responses. Back in 
the land of mrix one doesn't want to reproduce complex cryptography and 
authentication code in each module. Rather modules such as rshd or mrBluetooth can 
ask questions on behalf of a trusted security module, pass Alice's responses back to this 
' 20 secure module and if successful obtain a abstract token, an identity. The bank would not 
wish ever cashier to know all the permissions and information about all its customers. 
Typically after authentication it allows a cashier to view a subset of the information for 
that customer. The cashier cannot access evety scrap of information, just what is relevant 
to the task at hand, likewise charlotte the cashier cannot access the information or an 

25 arbitraty user, JUST the user that has been authenticated. There may be different ways of 
authenticating Alice, and this step is clearly separate but sequential with actually taking 
advantage of Alice's identity. In mrix each component CAN Use the core security module 
to challenge the user and get an abstract identity module. Using diat module mrContacts 
or any module can query the system for per identity policy and permissions. Finally the 

30 system only loads modules and command tiiat it ^trusts'. 



C. Target system 
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This section describes the target security in mrix. It is written in the present tense 
though some of what it describes may not yet exist A separate document describes the 
current state of affairs. 

5 C.l Underlying implementation 

The core of mrix is based on 

• mSecure — this single EPOC server combines the functionality of 
mStream/mldentity/mrBoot and in doing so offers greater security and 
functionality witii less overhead. For example where as it took at least 12 calls to 

10 2 different servers previously to request a pipe processor it now only takes 2 calls. 

Various wrapper / helper libraries layered over tiiese core systems 

C.2 Identities 

ft 

mm security is based on the coQcept of identities. Identities are an abstract concept 
similqf to user id's or principles. Pipe processors are invoked on behalf of an identity and 

15 dius can behave differendy according to which identity it is. Identities are represented in 
the system by identity handles ( tokens ) which can be passed between modules and 
processes if so desired. Identity handles can only be created as a result of an 
autiientication process. Given an identity a module can query for permissions and other 
settings for tiaat user. In addition to die identity invoking a module tiiere is also a second 

20 identity available to modules, tiiat being die identity that created/authored/signed that 
module. 

C.3 Pipe processor meta-data 

Each pipe processor ( including but not limited to scripts ) can be supplied with a 
separate meta data file. This file itself is signed and so modifications to the meta data can 
25 be detected. The meta data includes 

• A hash of the pipe processor die file corresponds to 

• Copyright , Version, Licence and author contact information 

• Permissions and modules required by die pipe processor ( ie dependencies ) 

• Permissions embedded in die pipe processor ( ic policy ) 
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The contents of the file is initially created as a text document by the author and then 
signed/compiled by die txt2mrix utility. 

C.4 Authentication 

mrix provides several types of authentication including private/public key, plain text and 
5 hashed authentications. Such credentials are stored encrypted on die device memory. 
The encryption may be fiirtiier enhanced in some configurations through the 
collaboration with trusted hardware (ie a SIM card) 

Rshd challenge the remote peer running mrCmd so as to audaenticate die user. The form 
of the authentication is negotiated between the server and die peer. 
10 Authentication mechanisms include 

• Plaintext username/password — simple but secrets may be in plain sight 

• MD5 hash of username/password and challenge — Each time an authentication is 
needed a unique key is used as a challenge. An algorithm is used to generate a 
hash from this key, and a secret known only to the trusted entities. Both ends 

15 perform the same has algorithm, if the transmitted result is the same as the 

expected response then it follows the peer must know the secret. By transmitting 
the hash the secret need never be revealed over an unsecured link, by using a 
vmique key each time previous responses cannot be used in subsequent 
firaudulent authentications. 

20 • Public/private keys — on their own public private keys can be used to prove that 

the peer is a holder of a private key. Certificates can be used to link that 
ownership to a real world identity. By taking a document and creating a hash of 
it, and then encoding that hash with a private key a document can be signed. 
Changing the document changes the hash and thus invalidates the signature. 

25 mSecure uses this property to sign meta files, and consequendy allows scripts to 

be executed with a selected identity without the need to embed plain text 
credentials in the scnpt itself. 

C.5 Permissions and Policies 

mSecure provides encrypted storage facilities for each identity it manages. Since pipe 
30 processors can be signed/authored with identities this means each pipe processor *can' 
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have access to its own secure private storage. Within that storage mSecure offers per 
identity sub-storage. For example mSecure provides storage to the identity of the 'rorFile' 
pipe processor. mrFile can store permissions and poEcy data in this storage such that no 
other identity can access this data. With that storage space mrFile can store separate data 
5 for the identities "John Doe" and "Anie Won", mrFile can this check the 
'settings/permissions' for JohnDoe' . If a script is signed with the mrFile identity then it 
can access this storage. This means scripts can be used as part or administration and 
configuration for pipe processor permissions and policies. The data that can be stored in 
this encrypted storage is a hierarchal name value stmcture. Each name value pair can 
10 store a different value for each identity. A comparison might be made with a source 
control system where there are folders and sub files. Each file in addition may have 
various versions. The name value pairs are Unicode text. The storage does NOT support 
raw binary data. 

* 

15 When identities are removed from the system, for example when pipe processors are 
uninstalled the associated storage can be automatically deleted. The storages are persisted 
in the file system in an encrypted form. The encryption of these files can be further 
protected by using keys which themselves are kept in secure hardware. If this is done 
then even if the file system is subverted and the data transferred to a different device the 

20 absence of the secure hardware ( ie a sim card ) means the data cannot be read. 

With this level of system support the core pipe processors allow fine grain control over 
their behaviour. For example mrFile allows read/write access control to different areas 
of the file system. 

C.6 UI for User Configuration 

25 In order to manage the identities and associated data on a device mrix includes a user 
interface component called mrixConfig. This user interface allows the following • 

• Addition/Removal of (user) identities with arbitrary authentication data. 

• Addition/Removal of scripts and pipe processors ( themselves identities ) 

• Granting and revocation of permissions and policies for the above 

30 

It should come as no surprise that the the user must authenticate themselves before they 
are able to use the user configuration tool. This allows for shared use of a mobile phone 
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for both personal and corporate use. le if the phone is purchased by an individual they 
may grant a subset of their permissions to a corporate IT identity that can be used to 
install and remove corporate applications and data. Whether the individual can later 
administer these corporate apps and data is up to the ^contract' between the individual 
5 and the corporation. Mrix allows a range of options to be selected. In this case the 
individual always has the choice of purging such applications and data from their phone 
if they so whish. Alternatively a corporate may own and issue a mobile device to an 
employee and grant them permissions to install and nm personal applications. Again 
while this data is private to the individual the corporate may . purge it if they wish — as 
10 . they were the granter of permissions to the individual in the first place. Such sharing of 
the phone allows an identity to grant and delegate permissions to other entities. Typically 

there might be soine financial agreement in place for this sharing but this is outside the 

» 

scope of mrix at this time. That said the facilities provided by mrix can be used to 
implemeat chargeable services. 

15 

* 

C.7 Installation - Mrix Cote 

4 

The mrix core may be burnt into rom or installed as an additional component after a 
phone is purchased. Initially mrix uses an identity called 'factory default'. This identity 
may be used to create additional user identities to administer the phone. Such as 
20 corporate IT department and sony online gaming etc. 

C.8 Installation - 3"* Party 

File locations for installation are as for the mrix core. Note however that tiie Identity.ini 
file needs to be modified for each new pipe processor dll. Scripts currently do not have 
*allow' permissions and so all scripts can be invoked by anyone. The behaviour of such 

25 invocations is obviously subject to the behaviour of the pipe processors it uses, in turn 
dependant on the identity used by the script. Other that running or examination a script 
there is no practical way of telling if a script will execute as expected for a given identity . 
Finally any user can install any pipe processor on their phone regardless of licensing on 
the pipe processor or ownership of the phone. ( ie a phone supplied to an individual by . 

30 their employee for buisness use ) 
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Appendix 1 

MRIX - Getting Started Guide 
/./ MRDC Overview 

m 

5 mrix is a platfotm agnostic \dreless network operating system. It is designed to allow 
rapid cross-platform development of a wide range of mobile applications both on and 
between smartphones, personal computers and servers. It consists of a powerful set of 
command-line driven tools which can be built upon and combined into sophisticated PC 
applications using scripting languages. In addition, mdx can be used to script applications 
10 that can be executed on the smartphone itself. 

Figure 2 shows a possible mrix architecture. 

mdx consists of a number of elements which can be used to run comma n ds over local 
15 links QR, Bluetooth and USB) as well as via a remote relay (TCP/IP, GPRS) as illustrated 
in Error! Reference soxirce not found.. 

There are several key elements of the architecture: 

• m-Router: Bearer connection agent m-Router consists of a number of both PC 
20 and smartphone components. It enables communication between a smartphone 

and a PC over a variety of short-link bearers: IrDA, Bluetooth, USB and Serial. 

• Relay: The relay, mrElayD (the T)' stands for daemon) allows remote access 
firom a PC to a smartphone via GPRS. The PC and smartphone both connect to 
the relay in order for communication between them to occur. 

25 • Identity server: All commands are run, whether locally or remotely, on behalf of 

an "identify" (person or system). Different identities may be configured to run 
commands with different results. . 

• Boot server: Handles mrix events to be started on smartphone reboot. 

• Command interpreter: A command interpreter module, rshd, runs on the 

* 

30 smartphone and is normally set up to start up on boot. 



wo 2005/046272 



29 



PCT/GB2004/004701 



• Command shelL A command shell, mrcmd, runs on die PC. The shell cutrendy 
runs on Windows but will soon be available on Linux and Mac OS X. Programs 
and scripts can be written for the PC that communicate and interact with mrix 
components on the smartphone. 

• Lua scripting engine: Scripts written in Lua (http: / / ww w.lua.org^ can be run 
on a smartphone. A number of useful scripts, e.g., SMTP and FTP clients, are 
provided with the release. 

• Pipe processors: Discrete smartphone modules that can be accessed through 
the mrix command environment to provide access to a range of smartphone 
functionality. 

1,2 Prerequisites 

Usage of mdx requires the following hardware and software: 

• PC with IrDA or Bluetooth support 

• Microsoft Windows 2000 or later 

• m-Router 

• mrix 

• Smartphone (Nokia 7650, 3650, 6600, N-Gage, SonyEricsson P800) 
13 Using MRIX 

1.3.1 m-Router - connecting to the smartplione 

« 

On the PC open a command prompt and type 

# 

>mrouter — h 

This command displaj^ the help for m-Routcr. All commands have a help option that 
can be invoked via -h or the long form --help. 

To search for smartphones to connect to type 
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>mrouter — c search-devices 
i 

This command option searches for all the Bluetooth devices in the locality. 

5 

The first foiar colvimns listed are an arbitrary ordinal listing number used to represent the 
device, the UID (for smartphone devices this will be the IMEI number — in this example 
it is only shown for device 8), the Bluetooth address and the Bluetooth friendly name 
(assigned by the user of the device). 

10 

Find your smartphone from the resulting list of devices then connect to the smartphone 
by typing the following command at the command prompt 

>mrouter — c connect-device — d <Bluetooth device name> 

15 

For example if your smartphone has a Bluetooth name of Nokia7650 then the command 
would be 

>mrouter — c connect-device — d Nokia7650 

20 

You will see the screen of the m-Router icon in the system tray turn firom red to blue. 

You may find that for development purposes using the ordinal resulting from the 
"search-devices" is the most convenient. You can connect to a smartphone using a 

25 variety of addressing schemes. The "-d" option takes the form <schema>:<id>. Schema 
can be one of N, IMEI, BTADDR, BTNAME, ANY. If not present, schema is assumed 
to be ANY. N will match against the listing number next to each device returned by list- 
devices or search- devices. IMEI matches die UBD field. BTADDR matches Bluetooth 
address. BTNAME matches device BT fidendly name. ANY matches all the above. So, 

30 it is possible to connect to a device in various ways thus: 

>mrouter —c connect-device — d 8 

* 

>mrouter — c connect-device — d IMEI :xxxxxxxxxxx 



■ 
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>mrouter -c connect-device -d BTADDR rxxxxxxxxxx 
>mrouter — c connect-device -d SJC xxxxxxxxx 

To disconnect from the smartohone, type 

5 

>tnroutet — c discotmect-device — d <Bluetooth device name> 

You can also type 

10 >mrouter — c disconnect-device — d - 

where a period stands for the currendy connected device or the first connected device if 
more than one device is currendy connected. 

15 1.3.2 mrcmd — controlling the phone firom the PC 

mrcmd is a PC side program that allows you to run pipe processors and scripts on the 
smartphone. Before running pipe processors and scripts on the smartphone it is 

necessary to set up the requisite level of security for your mrix setup. This is done by 

* 

20 setting the mrcind environment variable. At present, identity configuration information 
is stored in the \system\mrix\idenrityini file on the smartphone. A CTO identity has 
been set up in this file with a password of GOOD. You should use this identity for 
playing with the mrix system. This can be done from the DOS command shell as 
follows: 

25 

>set mrcmd=4 CTO -a GOOD 

Alternatively you may wish to set this permanentiy thus: 

Right click on *My Computer' on your desktop and select ^Properties*. 
30 - Select die 'Advanced* tab. 

Click the ^Environment Variables' button. 

Click the *New' button in the ^System variables' list. 
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Enter "MRCMD' into the "Vadable' field and '-i CTO -a GOOD* into the 'Variable 
Value' field. 

Click OK three times to save the change. 

5 Once security has been set up, you will need to start up the remote shell daemon, rshd, 
on the smartphone. You should only have to do this once the first time you run mrix on 
the smartphone. Thereafter, rshd will be automatically started at boot using the mrix 
boot server. To run rshd, you need to open the mrix application on the smartphone and 
execute the first command in the list box which should be: 

10 

mrtcp 

—accept —local 3011 —run "rshd —run" 

The mrix application is a simple way of running comm a nds and scripts on the 
15 . smartphone- To invoke another command from mrix just simply overwrite an existing 
command line (and any necessary parameters). 

Now you are ready to try running an mrix command using mrcmd over an existing 
mRouter connection. You may tiy out any of die wide range of existing pipe processors; 
20 mrps and mrfile will be described here. 

Connect to die smartphone using m-Router. 

To view all the processes running on die smartphone, type 

25 

>mrcmd . "mrps -1" 

mrcmd tells die smartphone (in this case denoted by a period which means the currentiy 
connected device but you can be explicit and specify the Bluetoodi name) to run the 
30 mrps pipe processor with the -1 option. Notice that die command is enclosed in double 
quotes. 



To get help on mrps from the conmiand line, type 
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5 



15 



>mrcmd . "mips -h*' 



To send a file to the smartphone, type 



>mrcmd . "mrfile -w c:\system\defaultcar" < c;\rarix\bia\default.car 



This command redirects a file (c:\mrix\bin\defavilt.car) to the smartphone. The '-w* 
option specifies where on the smartphone the file should be written 
10 (c:\system\defaiiltxar). 

To delete the file firom the smartphone type 



>mrcmd - "mrfile .-d ciXsystemXdefaultcar'' 



To get help on mrfile firom the command line type 



>mrcmd • "mrfile -h 



99 



20 Lua scripts can also be invoked using mrcmd. To get help on ru nn ing lua scripts firom 
die command line, type 

>mrcmd . "luanm -h" 



25 Create a script file called testlua and copy and paste the text between (and not including) 
the chevrons to the file 



#lluarun 

30 mrix.write("HeUo, World!\n*') 

— run the mrprompt pipe processor 

— mrix.run runs other scripts and pipe processors and has the form 
~ mrix.run(command, cotimiand parameters, [optional input]) 
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res = mrix.runC'mrprompt", "-t YESNO -p \"Need hclp?\"'0 
mrix.writeC'Result = "..res.,"\n") 

Lua scripts can be tun on the smartphone in one of two ways: 

• by streaming a lua script to the smartphone 

• by tunning a lua script that resides on the smartphoiie. 

To stream the script to the smartphone, type 

>mrcmd . "luarun < testJua 

The script will print, "Hello, Worid!" at the command line. By this method the script 
does not have to be resident on the smat tphone. 

» 

To run the script from the smartphone, first write the script to it. 

>mrcmd . "mrfile -w c:\system\mrix\testiua" < testlua 
To tun the script, type 

■ 

>mrcmd . "luatun c:\system\mrix\test.lua" 
The result is die same as running die script by the first method. 

* 

Lua can be invoked intetacttvely as in the following example thus: 



>mtcmd . "luanon" 
>mrix.write("Hello, Wodd!") 

>q 
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* 

• » 

For help on lua, check out the following resources: http:/ /ww w.lua.org, http:/ /lua- 
users.org/wiki/TutQrialDirectory . Review Intuwave's extensions to lua in the mrix 
documentation. 



5 1.3.3 More On Scripts 



There are two ways to run a lua script on a smartphone independent of interaction with a- 
PC. 

* 

10 The first is to invoke it using the mrix application. Simply type the name of die script m 
the Cmd field and any parameters for the script in the Params field and select Run. 

The second is to have the script run when the smartphone is turned on. To do this you 
have to setup an event that loads die script into the boot file of the smartphone: 

15 

>mrcmd . "mrevent -a -n runmyscript -e BOOT -c luascriptlua" 

This command adds (-a) a boot command (-e BOOT) to the boot file of the smartphone 
to mn a script (-c luascript.lua) when die smartphone is turned on. The event is given a 
20 name (-n runmyscript) that acts as a handle such that it can be removed from the boot 
file thus: 

>mrcmd . "mrevent — d — n runmyscript" 
25 1.3.4 Identities 

All mrix smartphone scripts and pipe processors are run, whether locally or remotely, 
imder the permission of an identity. An identity consists of a username, password and a 
set of permissions governing which scripts and pipe processors may be run under that 
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identity. The identity file, identity.ini, is located in the \system\mrix directory on a 
smartphone. 

So far we have run commands via mrcmd using the user, CTO (which has full 
5 permissions for all commands). If a smartphone is setup to run a script when it boots 
then the default identity it will use will be "Guest" which has minimal permissions. The 
script will therefore be limited in the mrix commands that may be run. To do anything 
useful the identity must change so that the script may take on more permissions. Edit 
the lua script file you created earlier. Copy and paste the text between (and not 
1 0 including) the chevrons to the file. Then use mrfile to send the script to die smartphone 
and run it using the mrix application. In mrix select Options \ Rim, enter "test.lua" into 
the Cmd field (make sure the Params field blank) and select Run. You will be presented 
with a prompt to which you may select yes or no. 

#lluarun 



— save the current identity, in this case. Guest 
old_jd = mrix.getcurrentidentityO 

2,0 — make a new identity handle using the CTO usemame 
new^d = mrix.makenewidentity("CTO", "GOOD") 

— use diis newly created identity to run die following commands 
mrix.setcurrentidentity(newJi€^) 

25 mrix.write("hello, woridI\n") 

— run the mrprompt pipe processor 

— mrix.run runs otiier scripts and pipe processors and has the form 
~ mrix.run(command, command parameters, [optional input]) 

res = mrix.runC'mrprompt", "-t YESNO -p \"Need help?\"") 
30 mrix.write("Result = "..res.."\n"); 

~ restate the saved idendly 
nirix.setcuircntidentity(old_id) 
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— release the new identity to &ee up resources 
mrix.releaseidentity(newLjd) . 
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Appendix 2 

Mtix 2.0 Kernel Internals 
2 Introduction 

5 The mtix v2 kernel runs as a Symbian 'server' in its own process/thread. Clients make 
calls to the kernel via MrixClient. The kernel itself is made of smaller modules, Basic 
primitive objects are contained in a module called MrixKemelObjects such as pipes, 
bundles, string and links. Anodier module MrixKemelldentity builds on these classes to 
provide identity/policy services. A Third module MrixKemelTasks adds the ability to 

10 create and run tasks provided by dlls, exes and scripts. Finally MrixKemel implements 
the actual Symbian server and session classes that drive and co-ordinate the afore 
mentioned modules. All these modules are currently dlls. A small stub executable 
(MrixKemelLoader) loads these dlls and runs diem in its process spkce. In a MUCH 
future versions of the kernel all these modules may need' to be combined into a single 

15 executable to prevent the individual dlls being subverted. Much of the security of tiie 
kernel is a result of combining various classes. To some degree the whole picture may 
only become clear when all the modules are understood, HOWEVER it should be 
possible to understand the role each module plays individually. Hopefully this will allow 
maintenance of the various parts with minimal if any impact on other parts ( keeping the 

20 exported API's the same where possible. 

The class stmcture of the kernel (see Figure 4) at first glance may seem complicated but 
it is built on recurring patterns and layers so tiiat ( hopefully ) it is simpler than expected. 
25 A Portion of this class structure is shown at Figure 5. 

3 MrixKemelObjects.dll 

With the exception of a utility class 'CUtil_Logger' that provides text file logging 
functionality, most of the classes are derived from or related to an abstract 
30 MSharedObjectBase class. 
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3.1 Base classes 

A default implementation of the MSharedObjectBase class is provided by 
CkemLObjectBase. This has a related factory class nested inside it called CManager. 
Other classes are derived ftom these classes to provide a repeating implementation 
5 pattern. CKem_ObjectBase provides reference counting methods however when a 
reference count reaches 0 the object is NOT deleted immediately^ but rather an active 
object in the manager class asynchronously garbage collects all null objects. There are a 
few advantages in this delayed deletion. 

• Classes such as Strings which reach a reference count of zero can be looked up 
1 0 and 'rescued* and their reference count incremented if they are required before 

they are actually deleted. • 

• Since deletions are done asynchronously if a pointer to an object valid at the start 
of a function it will still be valid at the end of tiiat function even if it is released 
by some function called during die execution of that function. This was a cause 

15 of some access violations in mstream and while it is possible to code such as to 

avoid such problems ( and this was done in some places ) die code then looks 
slightiy more complicated. This scheme side steps the problem by ensuring it 
doesn't happen in the first place. It also simplifys problems with circulare 
dependencies. When an object is released it releases the objects it references. " 

20 Rather than being deleted immediately ( and thus potentially causing coding 

problems ) the object is deleted later AFTER this object has fully detached itself 
and been deleted. 

• Calls into the kernel can execute faster since memory release and compaction are 
handled at icfle time rather than in the context of a synchronous client initiated 

25 operation. 

• It avoids some calls to the cleanup stack on object creation. Traditionally one 
pushes new objects onto the cleanup stack liberally knowing that they will be 
deleted if some method leaves. One aspect of the delayed reference counting 
scheme is that objects are created with reference count of zero. Unless something 

30 takes ( partial ) ownership of an object then it is later garbage collected. While the 

cleanup stack and trap harnesses are a .GREAT thing they do incur some 
measurable performance overhead and so they are only used where NEEDED. 
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The Factory/ Child pattern is taken advantages in several derived classes. For example the 
manager for CKem_String arranges its children in an ordered list and alloT^ lookups on 
that list — providing a sharable dictionary of strings. One advantage of this is that 
common strings such as "c:\systemlibs\mrix\mrFile.dll" and "Guest" etc are stored 
5 ONCE and shared between interested classes. In another example The CKern_Link 
manager allows all the objects used by a session to be tracked and validated (more on this 
later). 

Some classes in other modules such as CKern_Library and CKera-Authenticator 
themselves are further derived from to provide more specialized classes. At present these 
1 0 sub classes ( library types and authcnticator ) types are part of the kernel. Mechanisms 
COULD be added to the kernel to allow external or third party subclasses though this 
obviously has security implications ( third party code loaded into the kernel memory 
address space ) 

Some operations provided by classes are by nature asynchronous. An abstract base class 
1 5 MSharedAsyncRequest is used to encapsulate such operations. A CancelRequest victual 
method allows cancelling of such requests. 

Every instance of a MSharedObjectBase derived class has a ^Handle' that uniquely 
identifies diat object in the kernel. At present this handle is actually the 'this' pointer ( 
since its imique ) but this should NOT be assumed as it may well change in future 

20 versions of the kernel for security reasons. If a Handle is known a CManager can be used 
to search for an instance with that matching handle. Thus we DON'T cast handles to 
pointer only pointers to handles. Having said that, CKem_Link objects mentioned 
below delegate to die object tiiat they aggregate for tiiis HandleQ value. 
The objects owned by a CManager derived object can be iterated by using a templated 

25 iterator. This steps through all the owned objects and for each attempts to provide the 
requested interface, die iterator silendy stepfe onto the next object if that interface is not 
available. There is NO CASTING OF HANDLES TO POINTERS. 
Objects may be shared by different parts of the kernel, and thus can be shared by clients 

■ 

of die kernel by reference to handles. This exposure and sharing of objects by their 
30 handles is performed by MrixKernel.dll using flags ( access rights bits ) provided by 
CKem_Link objects implemented in MrixKemelObjects. 
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3.2 Object Classes 

This section briefly explains the pvitpose and aspects of the primitive classes provided by 
MtixICemelObjects. 

■ # 

3.2.1 Pipes 

Pipes are binary byte FIFOs. A pipe has 2 ends. The ends are a reader end and a writer 
end. Bytes written into the writer end are buffered inside the pipe to a certain amount. 
These bytes can then be read out of the pipe in the same order in which they were 
written. The writer can *close' the pipe. This means that no more data is allowed to be 
written into that pipe. Bytes can still be read out of the closed pipe until the pipe is 
empty at which point the reader will return an error ( EOF ). 

As data is written into die pipe a count is kept of the bytes written into it, conceptually 
tfiis is the length of the pipe. When a pipe is closed a reader can retrieve this value and 
thus knowing how much it has already read how much data it has left to read. The writer 
CANI specify this 'pipe lengdi' in advance for example if spooling a file of known length. 
It is then not allowed to write more than that amovmt of data in total to the pipe. ( at the 
poin.t at which that length' is reached the pipe is automatically closed ). If the reader 
requests the lengdi of a pipe before it is unknown then the value -1 is returned. 
This pipe lengdi is NOT die amount of data the implementadon of pipe may buffer 
inside it. The amovint a pipe could buffer internally used to be 4K, it is now 256b3rtes 
however clients should not assume any buffering size. Reducing the buffering size for 
pipes means that the memory per pipe ( and effectively die mrix kernel ) is 1/16'*' of 

what it was previously. As the buffer size is reduced more IPC calls are needed to 

» 

transfer the data in smaller chunks and this adds delay. 256 bytes seems to be a 
reasonable figure diat is *fast enough' while not eating up *too much memory*. Currendy 
die circular buffers for pipes is allocated from die heap of die kernel, while such buffers 
are smaller a future improvement would be to use 'Chunks' diese are memory allocations 
provided by Symbian taken from a global memory pool rather dian the heap of the mdx 
kem.el. 

The implementation of the class uses MSharedAsj^cRequest objects to read and write 
data from a circular buffer. An example might make some sense as to how diis works. A 
client might make a request to write 16K of data into the writer end of a pipe. The pipe 
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implementation fills as much of its 256 byte circular buffer with data from the client 
BUT DOES NOT COMPLETE THE CLIENT CALL YET. Either before or after this 
time another client may try and read 8K of data from the pipe. The pipe will vnite as 
much as it can ( 256 bytes in this case ) to the reading client. BUT DOES NOT 
COMPLETE THE CLIENT CALL YET. It then checks if it can refill its circular buffer - 
from any writing clients which in this case it can and another 256 bytes is read from the 
writing client into the circular buffer. It then writes this out to the reading client, it 
repeats this loop until either the writer has no more data to transfer or the reader client's 
buffer is full. In this case the reader client buffer will fill first and at THAT point its 
asynchronous call is completed. It may make another call to read a further 16K of data 
and eventually the writer data will be consumed. At which point the client asynchronous 
call is completed. The pipe code basically shuttles data between 2 cUents ( 
processes/direads ) . It can do diis relatively easily and fast as it does not need to context 
switch for each 256byte chunk. Context switches are BAD ( ic they take time and slow 
things down ) so avoiding them is usxially a good idea. Reading clients CAN request that 
they read *one or more' in which case the pipe object will complete the reading 
asynchronoiis call when it has transferred as much data as it can ( ie if the circular buffer 
has become empty and it has transferred SOME data to the reader ). 
Clients can cancel requests in which case they are completed immediately. Adding 
requests or removing requests from the reader or writer ends of a pipe trigger an 
asynchronous ^kick* of the pipe transfer engine so even if the engine stalls ( which it 
never does/should ) it wiU be restarted when the next request is made/ cancelled. 
Since pipes are byte streams they carmot transfer Unicode strings as is. There is an 
encoding of Unicode text known as UTF8 (a nice feature of which is that western 
characters are still readable ) and tiae kernel is able to accept Unicode data and convert it 
to utf8 and then write that into the pipe. It does this in chunks to keep memory 
overheads down. 

3.2.2 Strings 

# 

Most programs use strings but these can be for different reasons. Some times the strings 
are programmatic things like filenames or field names, other times they may be user 
interface messages. Sometimes the strings may be 8 bit and other times they may be 16 
bit. Using 1 6bit strings obviously use twice as much memory as 8 bit strings and so they 
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f 
■ 

shoxild be used appropriately. All diat said strings are useful things and often diey are 
passed in and out of the kernel- In many cases a string may be heavily re-used. For 
example strings like "mrStorage" and " — Ust THING -option SOMETHING" may be 
used repeatedly. If the kernel kept duplicates of such strings internally it could soon run 
5 out of memory. To reduce the amount of memory required the kernel converts strings to 
pointers to shared String objects. The CManager class for CKem_String orders all strings 
in an array. Strings are searched for using a binary chop technique so if there are say 1024 
strings inside the kernel it only takes 10 string comparisons worse case scenario to find 
the matchin-g string. Once this is done string objects be compared ( case sensitively ) by 
10 comparing the 32bit pointer to the object This is fast. 

Strings can be ( and are often ) returned to clients by specifying the string Tiandle'. The 
client can tKen fetch die contents or enquire if they wish as to the length of the contents. 
The kernel converts Unicode strings to UTF8 equivalents so a client may request data in 

4 

either format. Passing a string across thread boundaries has *some' overhead over and 
15 . above passing a handle in a IPC request. Thus a client CAN speed itself up by passing 
string handles instead of strings, however it may do this at the expense of source code 
readability. 

3.2.3 Bundles 

^^undks are poor misunderstood creatures. Give them a chance and they will be nice to you at 
20 Christmas. 

Bundles are a data structure heavily reused used inside the kernel to provide name value 
pair lists. Internally a list is kept of string object pairs. There can be multiple entries in 
the list with the same value. Methods exist to add/replace/remoVe values based on a 
string key value. Keys are case sensitive. 

25 Each pair tias a 32bit flag word associated with it This is used by MrixKemel to control 
access to clients. ( more on this later ). Bundles can be shared between clients and can be 
watched for changes. That is a client can make an asynchronous request to Vatch* a 
bundle. Wtien that bundle is changed ( values changed , items deleted, removed ) then all 
clients watching that bundle are signalled. The client can then. resubmit their watch 

30 request and query the bundle for values. IN THAT ORDER TO AVOID RACE 

coNDrroNS. 
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3.2.4 Links 

CKcmJink objects contain pointers to other objects. They expose a 32bit flag word 
and aggregate the object they point to. The CKetnJJnk implementation overrides 
HandleQ and GetExtensionlnterfaceQ to delate to the aggregated object. 
5 Each client session ( later described ) has an associated CKem__Iink::CManager instance 
that owns all die ^links' used by that session. When a session passed in a handle to an 
object it is validated against the list of objects *known' to that session. In reality this 
checks they are in the CManager instance for that session. At die same time the type and 
access rights (i.e. tiie 32bit flag worc^ are checked for the operation the client is 
10 requesting. When a session is released so are ALL the links owned by that session ( via 
the CManager object ). A session may have multiple reference counts on a link but diis 
only equates to one reference count on the a^regated object object, 

4 MrixKemelIdentities.dll 
4.1 Identities 

•15 Conceptually all actions are done by an identity and act on a resource owned by ( usually 
anottier ) identity. An identity might be a human being, a remote automated process, an 
application, a authenticated script. An identity has some unique NAME that can be used ' 
programmatically to distinguish an identity. An identity may also have other human 
readable names or descriptions, but essentially an identity is a named 'actor*. When an 

20 identity is referenced there is always a degree of certainty/ uncertainty that the identity is 
REAULY the identity claimed to be. In real life how can a person prove that they are 
who they claim to be? 

When an identity acts on another identity's resources diere is some policy as to what is 
permitted and how things should behave. In die kernel the identity owning the resource 
25 is called the CONTEXT identity. Thus an identity such as CTO may act on resources in 
the context of mrFile. Unless a client explicidy sets its context then a shared global 
context is used. 

Each, library ( explained below ) has an identity, currendy this identity is autogenerated 
based on the name of the library, but in die future this identity might better be obtained 
30 as a result of signing the library with a digital signature. 
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There are some special *stock object* identities that can be requested. 

• Guest — an identity used by default for un negotiated external peers 

• DefaultUserldentity — an identity used by user interfaces and other local' 
modules that has *full* permission. In the future it is possible that this identity will 

5 be come a ( changeable ) alias for another identity. It is also likely that in die 

future the default user identity may not have complete admin rights to the device, 
but in this version it does. It is also possible that Applications and code 
requesting and using this identity may need to be signed or authenticate 
themselves via some pin code entry. ( this has obvious user interface 
10 considerations) . 

• SharedGlobalContext — This is the context shared by all scripts and all 'mr' 
libraries imless they explicitiy specify another context to use. 

One can imagine a matrix of separate policy/permission stores, as shown in Figure 6. 
Within each store are name value pairs ( implemented currentiy as bundles ) however 
15 there is nothing to stop such policy stores from being stored as expressions or other 
binary data. What is important is to recognize that there are such logical 
poUcy/permission stores/databases. 

% 

Though not shown in Figure 6, any identity can appear on either axis. The policy for a 

I 

20 given pair of identity and context may be nviU. In the implementation of this kernel the 
policiy consists of name value pairs but again this might change/ evolve ( if NEEDED ) 
In the kernel the CKem^Identity dass encapsulates a named identity and the degree of 
confidence that the identity is genuine. There are no policies or permissions owned or 
contained within that class. Rather the CManager dasss can be querried for such 

25 information. 

Remember tliough the identity manager is itself a resource and thus whether or not it 
actually allows read or write permissions to identity data depends on the identity of the 
person asking for this data. le the following situations arise. 

• Requesting Identity A wants to know what some setting for identity B is in the 
30 context of identity C 

Or 

• Requesting Identity A wants to modify the setting for identity B in the context 
of identity C 
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The CManaget class exposes functions therefore that allow such queries. 

Clients can set the context identity ( *C' above ) and (shoul^ be able to set the requesting 

identity ( above). 

The Identity manager currently enforces the following policy 
5 • Only the DefaultUserldentyity is allowed to request changes to policies. 

• The DefaultUserldentity is allowed to run any task/library 
Currendy all the *mr' libraries do NOT set the context to be their own identity and so 
default to the GlobalSharedContext Identity. The downside of this is that the names of 
settings for say ^mrFile' cannot conflict with the settings of say *mrContacts\ 
10 In the future removing an identity ( such as a user or a library ) might also delete the 
policies involving that identity ( else a device might fill up over time with old unused 
policies ) 

In the cvirrent kernel the policy information is held in memory as a bundle and read in 
once ficom a text file identity.ini at startup, it is ( given the rearchitecting ) possible for 
15 code to be trivially added to save and restore this data from a binary file. In the future 
such policy data could be stored in a Symbian database. In a future version of the kernel 
a portion of this policy data might even be stored in a SIM ( smart card ) 

4.2 Authenticators 

Identity objects can be obtained by name, however ideally they are obtained as a result of 
20 some authentication process. The actual mechanism for authenticating a user is 
independent of the identity itself an d how it is used. The CKem_Authenticator class and 
its derived classes can be used with a sequence of challenges and responses to negotiate a 
peer identity. 

The method of performing an audientication be it plain text or MD5 hash or certificate 
25 /signature challenge is independent of how the challenges and responses are transferred. 
In some cases there may be no challenge, for example in the plain text authentication as 
used by rshd tihere is a challenge that is zero bytes long ©. Having the authenticators 
inside the kernel mean that can access privileged identity data not available outside of die 
kernel ( ie passwords ) . In some future versions of the kernel the authenticators MIGHT 
30 use the SIM ( smart card ) to perform some aspect of the authentication. 

Currentiy the only implemented authenticator is a Plain Text Username Password 
audienticator. 
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Obviously negotiations may be incoming, outgoing or symmetric. When creating an 
• authenricator one can specify the local identity to present to the peer. And after a ( 
successful ) negotiation a CKemJdentity object representing the peer ( which includes a 
confidence level) is obtainable from the authenticator object. 

5 .5 MrixKemelTasks.dli ' 

This module builds on previous modules and classes to allow the execution of tasks. 
These tasks are executed inside libraries ( historically called pipe processors ). These 
libraries may be implemented in arrange of wajrs ftom polymorphic DLLS to executables 
to scripts. Figure 7 illustrates it. 

10 ' 

5.1 Tasks 

A CKem_Task object has a state that is one of 

• constructed, 

• starting, 
15 • running, 

stopped ( with a resxilt code ) 

It contains a number of properties ( implemented internally as a bundle ) including an 

• * « 

identity , input and output pipes and input and output environments. A task also has AT 
LEAST ONE library and command line pair associated with it. In the case of a script 

20 there may be more than one pair. For example a task might have the pair "myScript.lua" 
and " — run. thing^' but it ALSO has the pair **lua5.exe" and "myScriptlua — ^run thing". ( 
in fact the library's are pointers to CKernJibrary instances so a task has access to the 
identities of the libraries it is executing within as well as the identity it is executed BY. 
A client creates a task at which point various system resources are allocated. Then the 

25 task is started. Internally this actually marks the task object as startable; at some point a 
Ubrary will service this task and stop/complete the task with some exit code. The client 
that created the task may asynchronously wait for the task to start and or exit. 
When executing a task the identity that is passed in to execute as must be one of 

• a stock identity 

30 •an identity retrieved INSIDE a library for itself 
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• an authenticated identity 
ie you cant just claim to be the CTO identity, when ru n ni ng a task you have to prove it. ( 
even if by a known passAvord ) 

m 

5.2 Libraries 

• • • • . 

A library has a queue o£ tasks ( implemented as a CKem_Task::CManager ). Depending 
on the implementation of the derived class, the library will execute code in process or out 
of process which processes that task. 

In the case of polymorphic dlls this involves loading that dll in a worker diread. The 
polymorphic dll request:s tasks from the kernel. The Kernel associates the worker thread 
with the library that created it and passes it tasks to execute when requested. If the thread 
dies unexpectedly any tasks running in that thread are marked as 'stopped*. If the diread 
dies BEFORE a task is started then an unrun task is marked as stopped, this means if a 
BAD library constandy leaves in its constructor dien successive tasks will be marked as 
stopped ( with their result codes being set to the exit code of the thread ). If it did not 
^do this then it might be able ( as it did in a previous, version of the kernel ) be possible 
for the kernel to get stack in a fast loop constandy trying to load a library and failing. 
In the case of executables, currendy the derived library class creates an active object for 
each running task. That active object starts an instance of that executable. The executable 
makes requests to the kernel for its 'task' and the kernel matches up the client 
thread/process to the correct library object and active object. If the executable exits 
without setting the task as completed/ stopped then the active object detects this fact 
and sets the task as corrapleted with the exit code of that executable. 

Scripts are handled by their libraries internally delegating the execution to another libraiy 
which in turn may delegate again until it is handled by a library or an error occurs. 
Finally there is an as yet unused library class which runs INSIDE die kernel — it provides 
a hard coded / built in command MrixKernelCmd that can be used to administer 
identities and permissions. It could have been written as an external command but then it 
would have been necessary to expose internbal interfaces used by this library. 
MrixKernelCmd is curirendy unfinished/untested but it should be trivial to complete at 
which point the user will be able to administer permissions and policies in a secure way. 
All libraries appear to behave the same to clients. 
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Each library has an associate identity, curready this identity is auto generated based on 
the library name, however in the future this identity might be supplied as a result of 
signing the library binary with some certificate. 

Each library also has an *info* bundle associated with it Gurrentiy this bundle is empty, 
5 but in the future it might have auto generated data. Alternatively in the future this bundle 
* might be securely populated by supplying some meta data file widi a library. Such library 
data 'might' in the future include 

• Copyright 

• Version 

10 • Resource strings 

. Licence information 

• Author/Credentials for library execution 

• URL to get updates from 

6 MtixKemeLdll 

15 This is the module that pxalls everything together to create the kernel; it is shown in 
Figure 8, When the module loads it creates a CServer derived class. Clients can then 
request a CSession derived class. 

Note that because of the changes in Symbian IPC API's various mechanisms of IPC are 
abstracted. For example to get the second argument of a message one can use the 
20 function Int32(aMessage,2) etc. This moves the conditional compilation of code to a 
single part of the module. 

The CMrixKemelServer creates and owns several managers. 

CKem^String.CManager — this is the *dictionarj^ of ALL strings shared inside die kernel. 
25 CKern3imdle::CManager and CKem^Pipe::CManager are used as factories when clients 
need bundles ore pipes created. 

CKem_Identity::CManager acts as a factory for identity objects and also as the object 
that is queried for policies for those identities. 

CKern_Autiienticator::CManager creates authenticator objects of the requested type. The 
30 manager is initialised with a reference to die Identity manager so tiiat it can access 
password information and get and 'return' identities. 
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CKem_JLibrar3r::CMaiiager is responsible for finding/loading/imloading library derived 

9 

classes. 

* 

At server construction these managers are used to create several stock objects ( ie guest 
identity, null pipes etc ) 

5 Each client creates at least one session derived class. The CMrixKemelSession class 
handles requests from the client. Each session object owns an instance of a 
CKern_JLink::CManager class. As objects are created and handle reference retumed to 
the client a link object is added ( or reused ) that includes the permissions granted to the 
use of that litilr . When a client makes a request and passes in a handle value the session 
10 object uses the li'n1<: manager to validate that handle. It also checks that the link has the 
right flags ( bits ) set for tlxe requested operation. If the request is asynchronous then it 
creates an instance of ( derived firdrn ) to handle that request. For example. . 
icasi EOpWrit^^^ 

15 i iLcDks->]^^ 

CKemjjiik )^lkik= - 



20 !CanWtitc);i . • . " 

JEMcixKem 
'i'ti^=NewRequestLC0 

refq4>AdcDJb^ I '•' •[' }^ r" / . • ' ^ 

f)Writer->QueueWriteL(reqXeng^(aMessa^^ 
25 GleanupStack::PopAhdI>estroyO;//teq now owned by writer . . 

• . • • ■ . ... , . • 

breiak; • 

! ^ • • • • ■ ' ; . ... . 

This code fragment . . . 
30 • Logs the function being called, 

• Gets the object matching the handle passed in the 0* parameter of the message, 
checks that it is of type CKem_Pipe::C Writer and that the link for that object 
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owned by this session includes the mrix::KCanWrite flag. If any condition is not 
satisfied the method leaves with KErrAccessDenied. 

• Creates a request object that will use the client buffer identified by the 3"* 
argument of the message 

5 • Associates the link with that request and then 

• ' Calls the method on the writer object that will complete asynchronously - 

• Destroys the reference this code was holding on the cleanup stack since the 
writer has taken a reference count and now *owns' diat request. 

6.1 Handles and Sharing 

10 As mentioned each session maintains a list of known objects ( via link objects ) and has 
permission flags for these objects. Other than creating objects, clients can also obtain 
handles to objects if they are explicidy shared by another client . For example if client A 
has a handle to a pipe , client B cannot use that handle value imtil client A explicitiy 
shares that value to client B by specifying its session id. ( each client session has a unique 

15 id ). Also passing an object into a task or a bundle means that if the task handle is 
transferred to another client ( as part of running a task ) then the rights to the objects 
contained in that task are .ALSO transferred. 

6.2 Logging; 

The mrix kernel DOES include some powerful! debugging losing — possibly too 
20 powerful and so it is only compiled into the debug kernel by default. By creating a 

directory called c:\logs\mrixKernel penodically the kernel will domp out all the objects • 
it has in memory includin.g binary pipe data and otherwise secure data. le its ok for now 
for debugging inside Intiiwave on an emulator but don't ever let that code out into the 
big wide world as it defeats the point of kernel security. Also in the debug build 
25 components log as a result of base classes' For example for mrFUe if one creates a 
directory called c;\logs\mrFile then each client instance will log all calls made, the results 
and all data transferred. The following is an example. 

I - • 

* ■ 

•Started logging Completed request 0 • 

30 Begin command 

\ ^ • 

I IsLo^jmg 
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- Completed request 0 

J , — End command 

!29BDCFE4 Created share 

• # 

i29Bt)CEE4 Set share flags 00000007 
5 .29BDBE9C Created share 

i29BDBE9C. Set share flags OOOOOOOB. 

• - • 

;29BDC970 Created share . ! 
i29BDC970 sk share, flags OOOOOOOD 

1'*" • 'if -."S" ^ * * 

.. .. • • . . .? • . . •■ 

I-' • - - . ■ • .• 

j29BD98te ^Gieated share . J ; r ' 
10 :29Bdsi4-C^^et ^haire Bigs^OOOOboS^ - : 

i29BD t;C9C .^Greiated sharel ' 

l29BDCG9Cf '^iSet siiar^^ 

!:29BD9B90 Created shsie • . . 

20Bb9feS!6 let shar(5 flags Cf^Q^ 
15 *^»BD(aFB8 Created % : : f 

i29BDt;FB8 . Set sliareflags, ODdOOOOS' 

l2;9B0BB9G. .Cr^^ted share! 
i29BDBB9G ...Set shareiQfl^vp^ 

20 k---~ oilTasfcDetailk ; .r'i' ' 

■|2S>BDCFE4- Qbject pa^^^ ' 

^29BbGEE4 ' ■ ' LmkOliject ref=l : . 

;29Br>jCFE4 ' . , l%gs i? S ^Wi 

j29BDCFE4 . Taskre£=4 

25 :29BDCFE4 ' ' . Library .= Z:\Systern\ms\miix\]Vp^^ 

29BDCFE4 Paiattis = .-Usf 

29BDCFE4 State = Running 

i29BDD078 Bundle ref=l 

i29BDD078 Key=Stxnn Fkgs=OOOOOOOB 

30 ;29BDBE9C PipeReader ref=3 

I29BDC41 8 Pipe ref=2 

i29BDC418 Total = -1, Written=0, Read=0 

i29BDC418 Start == 0, Length=6, Max=512 
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20 



j29BDBE9C 
i29BDC204 

I 

i 

•j29BDD078 

'29BDC970 

i29BDC6A8 

;29BDC6A8 

i29BE)e6A8: 

!29BI)C9i0C . 

;29iD'!e970 ■ 
!^9BE»D0:;^K 

i • .■■-'!■■ • 

|i9BQ984e . 
29BD95E8 
!29BD05E8- . 
l^9fiiiD95E8 

• ■ • » ' 

i29BD984C 
'29KD9884' 

■ • ^ * 

i29iBDb078 
j29BDGG9G 

i. :-r 

I29BDC9D4. 



i29BDe9D!4 



i29BD.G9D4 

I ■ > • .* ,'•".* 

i2S»BDCC38 
l29BiDGC9C 
j29BDD078. 

■ 

25 :29BD9B9b 
;29BDD078 
|29BD9B90 
i29BDD078 
;29BDGFB8 
30 |29BDCFB8 
■29BPD078 
29BDBB9C 
i29BDBE9C 



- Accessor ref=3 
Accessor ref=l 
Key=StdiDut Flags=O0O0000D 
PipeWriter ref=3 
Pipere£==2.'. ; 
ToW = -1, Writtea=0, Read^O^ 
= Let^=0,tkax=.5i2 

. Acce'ssor fe£=l 

• • •. ... 

'." Accessor ref=3 . . 

PipeKeaier ref=6^ . 

■ . ■' T^tei = b;:#ritten=p, R^ai^p.^ .: 
* .'Start = Oi Length- 

-- : . ■ 

Accessor ref==:6 ' 
Accessor ref =3 i • ! . 
:::: Key^AxjixOut Flag^ ; . 

: ' ■ toM =:^i; WMttensio, I&a4-^P.- 

= 6^Leheth==0;T!{4x=5^ 



' -.! Accessbr ref=l " 

- • - • ■ • 

Accessor ref=3, . 

• • • • 

' Key=Env-In Flags=00000d03 
Bvmdle re£=8 
.Key=EnvOutr Flags=00000007 
Bundle .ref=8 

Key=Param Flags=00000003 

. ■ * • ■ 

String ref=4 
Value = —list 
Key=ldentity Flags=00000007 
IdentitjrRef ref=5 
Set share flags OOOOOOOB 
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20 



25 



30 



i29BbC970.- 

t 

•29BD984C 

|29BDCC9C 

:29BD9B90 

:29BD9B9d 



29BDCFB8 



'29BDBB9C. 



Set shire flags '66OOOOOD \ 
Set share flags 00000003 
Set share flags OOGOOOOD 
Set share flags 00000003 

• * • * * 

Set share flags 00000007 

. Set share flags 00000003 ^ 

• ' • . 

Set share fla^ 00.000007. - 



|-~r-'^ .Completed request 0 "... 



End.command ' 



29BI5BB9:G 

A .• * 



.*■ *J * * 4. 

ame • . i:. . • 
OBjbct piassed in A 
: -iliinkObject ■te£=2" ' 

. , . Fla^ = S3iW. .'■ 
f. -Identit5rRef ref=5 . 
— R^tutrdngjrisdiow string = CpTO Team 
1^—^: CksniRl^ted request Oi - 
14-^ — End comnlaad 
I'^'^-i --r-tTirr: Begui'coninxand 
fr^—— ^JetCo'iifideDcel^^ • 1 

Object passed in * " 
iinkObject ref=2 

Flags =. S,R,W; -^ ;' 
IdentityRef tef=5 . 



:29BDBB9G 
■ i29Br)BB9C 
15 129BDBB9G 
I- 

* • 



29BE)BBaG 



i29BDBB9C 



i29BDBBdG . 
!29BipBB9e' 
„J — Cpmpleted request 0 

: • • • . 

[J; End command 

■ -.-.Begin ™^ 

* ^ 

:„ GetldentitySetting 

! 

, String = AllowmrFile 

* * ■ 

29BDBB9C Object passed in . 
i29BpBB9C LinkObject tef=2 

* 

29BDBB9C Flags = SAW, 
29BDBB9C ' IdentityRef ref=5 
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20 



25 



30 



•'29BDEb94- Created share 
i29jBDE094 Set share flags 0000OOO7 
-r— Returning narrow string = YES 
Completed, request P 

End command \ 
Begin comtriand ; • . 
j-jl::i^v ^X^tePife*: /r ":.':, 
;29Bt)C970 . Object passed.in : .j 

JEinkObject refi=f2 . 

■ J; kags,=?eiSi^5(^ . 

- yC . ?ip^5(7ii^ 

tDe'tef=2'L' 



:29teD.C970. 

|29pbe970 
■29B3^)S^70 



29BDG6A:8'. 

! V •. - 

:29BDti5^8» 

I if ■•: ■■ • 

!2S>^D66A£i. 

; I -I • 

I29BDC®G 
!29B]^t:970. -, 



Total-^i. • Written^O, Reaa=0. " 

Sli^ .= 0;-Ii>eiigtfi=0,^]^^ 
Accessor rer==l 
: Accessor '.ref ==3 / 



• — . — Eiid confmarid; - . ^ ! 

29BDC970 Async^w^ite bytes * 

^Slibyte^ = 31^42F..31:?3i2B3^ 30 31 20 20 32 32 3A;35 34 09 20 20,20 20 20i 
::20-26; 20 20 20.20 i20 ^:36 2d..^l •^4 64^,^^^^^ 73 2E'64,6J5^V4 OD plA' 32 37 2F 3Q35 




130 36 09 3C 44 49 52 ;3E 20 2Q'26 20 20 2Q.'2Q 20 26 20:'62'6C 6E 6F 6D,62 65..72 67 32 i 
iob OA 30 39 2F ^0 39 2F 32 30 30 32 20 20' 20 34 3A 32 33 0^ 20 20 20 20 20 20 20 20'' 
'20 20 20.3;^ 39 36 20 63 6F 6E 76 65 72.74 65 64 2E 61 69 66 OD OA 30 34 2F 31 31 2E 
!32 30 30 33 20 20 20 32" 3A 31 34 09 3C 44 49 52 3E 20 20 20 20 20 20 20 20 20 20 43 
''6P 70 79 20 6F 66 20 74 65 73 74 OD OA 30 34 2F 30 39 2F 32 30 30 32 20 20 31 35 3A 
130 34. 09 20 20 20 20 20 20 20 20 20 20 20 35 35 34 20 63 75 72 72 65 6E 63 79 2E 77 
;6D 6C 63 OD OA 30 34 2F 30 39 2F 32 30 30 32 20 20 31 35 3A 30 34 09 20 20 20 20 20 i 
!20 20 20 20 20 20 36 34 36 20 63 75 72 72 65 6E 63 79 2E 77 6D 6C 73 63 OD OA 30 34 j 
'2F 30 39 2F 32 30 30 32 20 20 31 35 3A 30 34 09.20 20 20 20 20 20 20 20 20 20 32 37 36' 

^ " ' 

35 20 64 61 6C 69 2E 6A 70 67 OD OA 30 34 2F 30 39 2F 32 30 30 32 20 20 31 35 3A 30 : 



134 09 20 20 20 20 20 20 20 20 20 2 0 20 32 34 32 20 64 61 74 61 2E 77 6D 6C 63 OD OA ! 
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■532 39 2F 30 36 2F 32 30 30 34 20 20 31 39 3A 30 37 09 20 20 20 20 20 20 20,20 20 20 20! 
I20 33 34 20 44 62 52.65 63 6F 76 65 72 79 4C 6F 67 2E 74 78 74 OD OA 30 34 2F 30 39 ; 
i2F 32 30 30 32 20 20 31 35 3A 30 34 09 20 20 20 20 20 20 2Q 20 20 20 20 34 35 30 20 64! 
i65 63 :6k31 2E 77 6D 6C 63 OD / 

i' •. : : Ascii.= 14/ll/2p0r 22:54;" . • 6 address.d^t.27/p5/?0.02 I3:37j , 2196(57' ; 
jBitmips.log;.0.6/,06/2004 ■'2:06.<PIR> ', biboniberg2,;;09709/200^ = =4:23, .. 79.61 
!;coiiverteH.aif..04/l l/2003.> 2:H^I>m> Copy of itiBst^Q4/09/2002 '15:04. ^ 




l29Bi;^G?7b'Asmc Wtif^y^^ i:- v.',:?.; ■ 



1 1*: 



5i243ytes;.=^0A^ 2i0 34 2F 30 ^9 2F 32 30 '3G=32:2tf .2S 31-35 3A* 30 34 09 20 20 20^ 



!20 20 -20 20 20'2:0 20 20 32 3.6 39.20 64 6S<63 6B 32 61 2E 77!;6D 6C 63 0D OA 30,34 2F ! 
:30.39 2F32 30.30 32 izt) 20 31 SS'sA 30 34 O9>2O.20 20 2b 20 20 2Q 20.20,20 20 31; 31.33 : 

- - ' . . • •-...» • . / ■ * . •. • ■ . . - • , ... - * . , . < •■ 

: • . • ■- t • % ' - . ■* "*•'..• • . .. \ I. , . '^'t^' *' 

15 20.64 65 63'6B;-32 62 2E.#^D'6t: 63 OD OA 30 34! 2F.30 39 ^F,32 30;3b^2,26 20 31 35! 

jr.'.-- '■ ■ ■ ■■■<'■■ ;■■ • f. v'. .'wr< - ''. ■■ ■■ 

^30^4 .0^> 20 20 i20.20:2D 20 20 2Qlo:2a=20 34.35 3.6 20 64-65 63 6B 33 2E 77 6D 6C;- 

I . • • 1 • ■ - • • ~r - ,• * • «• , • 

i63;;6b M32.33 2F'30 37; 2iF 32 30 3d'33 20 20 3^ 30/3 A .3^ 30 09 3C #^9 52 3B.20 20 
:20^^0 20.26-20 20 20 -20 <54 6F^3 75 6b 65 6m-74 73 ob OA 30 33fi2F 30 39,2F^32 30 30. 
20' 20 31. 34 3A 3.1 32 £©.20 '20 20 20 io;20. 20 20 20 26~34^34-38-32 20.^64 6E 6'8 iZRv 

20 r77 61 76 6d.;0A 30 2(4 2F 3.0 39 2F. 32 30.30 32 20 20 31^ 35 3A 3Q.34 Q9m20 20 20 20- 
I20 20 26 20 20^0-33 33 3:1^20 67.'65 74 fe;6i 70 -69; 74 6I 6C 2E 77^6D'^C 73 63.0D OA 
!3.1 31 !^ 3p .38 2F 32 30 3O;33-^0-26 31 34r3A 33 34 09.30.^:49=52 3R2Q.20 20 2&^, 
20 20 20 20 20.69 63 6F 6E 73 OD OA 32 38 2P 3li^2 2F 32 30 30 33 20 20 31 34 3A 33 
!30 09 20 20 20 20 20 20 20 20 20 20 38 36 36 36 20 6C 69 73 74 4E 65 77 73 53 74 6F . 

25 172 69 65 .73 49 6E 53. 74 6F 72^1. 67 65 2E 6C: 6F 67'OD 0A32 38 2F 31 322F323p30 
i33 20 26 31 34 ^A 33 30 09 20 20 2 0 20 20 20 ^0 20 20 20 32 30 33 35 20 6C 69 73 74 53: 
i74 6F 63 6B 50 72 69 .63 65 73.49 6E 53 74 6F 72 61 67 65 2E 6C 6F 67 OD OA 32 39 2F! 
;30 36 2F 32 30 30 34 20 20 31 38 3A 35 30 09 3C 44 49 52.3E 20 20 20 20 20 20 20 20 i 

• ■ » ' 

[20 20 6C 6F 67 73 OD OA 31 36 2F 31 32 2F 32 30 30 33 20 20 31 33 3A 33 33 09 20 20 ; 
30 !20 20 20 20 20 20 20 20 20 20 34 35 i 
! Asdi = .04/09/2002 15:04. 269 deck2a.wmk..04/09/2002 15:04. i 

j • - - 

ill 3 deciE2b.wmI&.O4/09/20O2 15:04. 456 deck3.\railc.23/O7/2003 

j20:3O.<DIR> documents..O3/O9/20Ol 14:12. 4482doh.wav..04/O9/2OO2 
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•15:04. ■ 331 getCapital.wmlsc. .11/0872003 i4:34:<DIR> ' . ' icdiis..28/12/2bb3. 
.14:30. 86661istNewsStoriesIiiStorageJog..28/12/2003 14:30. 2035 
ilistStockPiicesInStoiage.log..29/06/2004 18:50.<DIR> . . . logs:.16/12/2003 13:33.- 

I •■ ■ ■. ■' .- ■ ■ "' • ..." ■ ■ ■ ••■ ••. ■■ • • 

I-* -'.*.•. • - .-. ■> - , ■•. 

■ * . ■ . . • ' . . . • • • ■ y * .V' . . • • ■ 

5 i29BDC970Asyiicv^e:byte^ ' ■ /- y ' y ■ - ' \\ 

■ : '* V512 bytes = 20 4D 44 53 20 44 65 6D Ob OA 30'36 21? 3;0 37"2F 32 30 30 3.3-20. 
|20'31 34 3A34 35 09^3G 44; 49 52 3E 20 20 20 2^) 20 20 20 20 20 20 6ID iSD 73 74 65 73 
i74^0D OA 30 34.2F 30 39:2F 32 3p 30 32-20 20 31 35 3A,30 34 0^ 20 20 20^0 20 20 iOv 
126 20 20 20 34 34 32 20 6DilF. 72 74- 67; 6^ 67 65- 2E 77 6D. 6G 6i^br)'bA.30'34 2F 30 ^ - 
10 139 2F 32 30.36:32 20 id 3:1 3^ 3A 30 34 09 20 20 20 20 20 2b;Sd-20^20 20; 2Q 31 36 32 20i 
^60 6E.72 74'67^6i:M65 ZE^7 6D'6C 73.63;QD 6A32 30 2F 3li:aa2F32;30.3p 33 20^^ 

« ' • ■ ' ." J ^ * '* . • 1 - " . V , • • , , S « • • 

i^aSl 32^i3A 32^3a69 2a:20 2iO 20 20 20^20 20:20 2a^ 20 ^2*33^ 20 :6^^^ 

!74 78 74 OiD'OA 32 33 2F 30 37 2F 32 30 30.33 20 20^323of3A 33* 0? 3C 44 49 52 3Ec" 

'ib 20 io 20.20 20 20^20 ^0 ^0 60 73 ;67 74,65 73 .74.0D .0A. :30^ iiP 30 30 i2532-3030;:;. 

15 132 2d'20.31 :35 3A 30 34 09120 20. 20- 20 20 2i0' 20 20 20 2Qii20 32 3,0 353'20 4D 75 6G .74 , 
i6Sr43 ^1 7i2 64 M';77 6I5/6tf iS3.0D-OA:32 33 2iF 30:37 2P'32 30^0.33 20.ib 32.3C> 3A 
i30 09 3G>I4 49 "52 3E 26 20:26:26 20 20-20 i20?26 20 6E 6F 6100 OA 30 38 2F 30 ,, 

130 2F;32 30 30 32 20 20 35* 32 3A 33 32 09 20 2b 20 20 20 20 20:^b'20. SO 2b38 33 36-20 ' 
6F-72 6'9 67:69 6E'61r6G 2E.6li69 66 OB' OA 32 30 2^31 30 2F32'30 30 33.!2Q 20.31. 35;' 

20 ISA 34 31 ;09 20 20 20 iO 26''20. 20.20 20 iZO 2Qi:31 31. .39 2d72i6;^61 74j2E-74..78.74 QG ' 
iQA'sa^ 2F-3035 2p 32 30^032 2:0-20 31 35 3A 36 34 09 20:20120 2Q .20^6 20 20 20^- 
I20 2&34 32.39 20 72' 656i 64;6©-65 2E 7:^*i5b 6C 63 OD OA 'Si. 38 3^iQ<33 2f' 32:^^0 
130 31 20 20-31' 31 3A.34 3'6 09 2020 20' 26 20-20 20 32 35 33 34 34'^36,;3b 20 7i 67 62:f5f?i 
171 63 69 66 OD Oa36 34 2F 30 39 2F 32 30 . . ■ . • - ' • 

25 ! Ascii = MDS bemo.:06/07/2003 14:45.<prR> . tnmstest..04/0972002 
IT5:04. 442 mortgage.wmlc..04/09/2002 15:04. . 162 . " J . 
jmortgage.Wsc..20/lp/2003 12:20. . 23 tnipvit.txt..23/07/2003 20:30.^DIR> . 
jmsgtest..04/09/2002 15:04. 205 MultiCatti.wmlc..23/07/2003 20:30.<DIR> 

inokia..08/09/2002 22:32. 836 originfll.aif.,20/ 10/2003 15:41. 119 

30 lidattxt..04/09/2002 15:04. 429 readmcwmlc l 8/03/2001 11:46. 2534400 

;rgb_qcif..04/09/20 

I29BDC970 Async write bytes . j 

• .. . . . . ..,....* .... ... .. ... .-. ~ .. , 
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; 512 bytes = 30 32 20 20 31 35 3A 30 34 .09 20 20 20 20 20 20 20 20 20 20 31 38 30 j 
jis 20 73 6D. 6F 6B 65 2E 77 6D 6C 63 OD OA 32 30 2F 31 30 2F 32 30 30 33 20 20 31 \ 
135 3A 30 38 09 3C 44 49 52 3E 20 20 20 20 2 0 20 20 20 20 20 73 79 73 74 65 6D OD OA ; 
•3p 342F 30 39 2F 32 30 30 32 20 20 31 35 3A 30 34 09 20,20 20 20 20 20 20 20 20 20 20\ 
33 32 3^ 20 74 61 62 6C 65 2E 77.6D. 6C63 OD OA 33 31.2P-31 32 2F 32 30 30 33 20:2di 
20 30 3A 35 38 09 3G 44 49" 52 3E 20 20 20 20-^20 20 2p 26^^Q'^2674;65 73 74 OD OA 33. ' 
l30 2F;30 37 2F 32 -30 30 33 20 2;0 31 34 3A 34 31 .09 20 20 20 2b 20 20 20.20 20 37 33 ST-j 
hi 38 20 74 65 73.74 2E 64 .61 .74 6ioD OA 32 39:^F sio 39f2Fi2.36 .30.33^ 20 2Q. 31 31^ 
iisA 33 30 '09 20 20 20. 20 20 .26 20 20 26 26. 3il' 36 iS^. 20 74 65. 73 .74 2]^.;74 78 74 dE> 




6E1 

' • .*. 

!72 53 7i6F .72 61:61 65 43 .68 61 6E 67i65?73 2E ;6Q6F 67;0E>-m 30; 36,2F:i30 35.-2F 3^1 
1-30 30 -^2 26 20 31 33 '3A 3033 09 20 26 20 20 20 20 20 ^febtlZO 20 ^ 20 3.6,20 77 62 6.e, 
15 i6F 67.^7 65 7Z2E^C 6E 67 OD OA 30 34 2F' 30. 392F.3.2-i36 30 32 20 20 31 35 3A 3^34; 
:0S>' 20 20 20 20 20 20 20 20 20 20 20 33. 30 3'6 20 ^^7 65 61 74. 6,6; 65 .72 2E 77 6D 6C 63,„;^-.| 
;OD-d^ 30 34 2F 30'39 2E32 30.30 32 20 20 Sl'SS 3A 30%:b9-20;2b 20 20 20:20 20:20 .j 
|20 20 20131 32 30 20 57.65 6G~63 6E .^D 6531 2E;^^7 6D/^fc.^63/0D .04 "30/34:2F,3Q/3^^^^^^^ ! 
2F 32 3030.32 20.20 31 35 3i^ 30 

Asdi;#'02i;r5;d4.;> .ll05 •smoke..^inialc■ ^ ^ :^ 

'i^stein..iD4/P9/i6D2 .15:04;' . . 326^^^ 



!test;v30/07/2Qb3 H:"4t. ' 73728= testdala.j29/09|^!^^^ 
!test.t3Et..2l/Q9/2003 15:37. ■ . ; l27 .test2.t=sc:.i8/l2/2Sb3f 14:30/ . . . 91? ' • 
:watciiFbrSto£ageaianges46g;.06/05/2002 1 3:03. ' 0 wblo^;^J6g..,04/09/2002 
25 Il5:d4. . .306 weather.wmlc.;64/09/2002 -15:04. . .;120 V ' . ;,• 

IWelcdmel.wmlc..04/09/2002 15:0 • '^'^ * 

i29BpG970 Async write bytes . T . 

I 216 bytes = 34 09 20 20 20 20 20 20 2 0 20 20 20 20 31 32 34 20 57 65 6C 63 6F 
{6D 65 32 2E 77 6D 6C 63 OD OA 30 34 2F 30 39 2F 32 30 30 32 20 20 31 35 3A 30 34 
30 i09 20 20 20 20 20 20 20 20 20 20 20 31 33 3 3 20 57 65 6C 63 6F 6D 65 33 2E 77 6D 6C 

1 

!63 OD. OA 30 34 2F 30 39 2F 32 30 30 32 20 2 0 31 35 3A 30 34 09 20 20 20 20 20 20 20 

j 

'20 20 20 20 37 35 38 20 77 69 6E 64 65 78 2E 77 6D 6C 63 OD OA 30 34 2F 30 39.2F 32 
i30 30 32 20 20 31 35 3A 30 34 09 20 20 20 2 0 20 20 20 20 20 20 20 34 33 32 20 77 69:6E: 
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10 



15 



20 



25 



30 



164 65 78 m n 6D 6C 73 63 OD OA. 31 38 2F"3a 33 2F 32 30 30 31 20 20 31 31 3A 34 36: 

i ■ ■ ■ ■ • - • • j 

;09 20.20 20 20 20 20 20 32 35 33 34 34 30 30 20 79 75 76 5F 71 63 69 66 CD OA • 
I Asdi = 4: 124 WelOTme2.wtiilc..04/09/2002 15:04. . 133 

I- 

]Wdcoihe3>ymcilc.04/0V2 15:04. . . 758^0adex.wtrAc:.O4^^ 

1432 >wiiad%wmlsc.. 18/03/2001 l"l:46. 25344bp yuvdcif.. . . . . .'. 

! t>'-.'.. - - . • 

i29BDE0EC Asyjac completed request 0 ' • • 



^ ,_.i_,.jBegin command 



pBDG:FE4' ' Object passed in ; ■ 
i^ofete • lihl^bject re^ 



. ■ ' • «• 

.•.-/* 



i29BDCFE4: 



i29BDCEB4 

i29BE)G:gE4-i 
!29BDD078 ? 



, .ref=2 ... ' 
library F:Z:\System\IibsXifiriiNj^^ 
Params =='--list 



. ,1* 



I29BDD078 

I 

■29BDGil.8:i 
|29BDG41«i 

! -:: . •. J?,r. • 
U\ *.N »-■ - . -' • • 

:29BDC4i8 
i29BDBE9C 

I * ' . 'i ■ \' 

i29Bbc2m; ' 



i29BDDd78' 

'■ •. ' 

I29BDC976 
i29BDG(SA^ 
i29BDC6A8 
.29BDC6A8 
29BDC90C 
;29BDC970 

I 

I 

j29BDD078 
j29BD984C 
::29BD95E8 



Stafe = Ruimtbg '\ 
; Bundle ref=l; \ 

' PipeRe^der j:ef=2; 

• ... • , .•• 

, Pipe ref— 2 

Total = -1 , 'Wiitteak=0/Read=^ 
• > Start' =0/I:ien^ 
s Accessor fcf=r2; 
^ " Accessor i:ef=i - 
Key=StdOut Flags=dOdOOpOb >^ 
PipeWriter ref =2 ^ ' 

• Piperef=2 . - ; / . - . ■ 
, Total = -1, Written=2:264, Read=2048 * 

■ * * 

Start = 0, Length=216, Max=512 
Accessor ref=l 
. Accessor ref=2 

Key=AiixIn Flags=00000003 
PipeReader ref=5 
Pipe ref=2 
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10 



15 



20 



25 



30 



29BP95E8 . 
.29BD95E8 
!29BP984C 
;29BD9884 
j29BliD078 . 
i29BbCC9C 
j29BDC9D4 
i29BbC9b4- 
! 

i29BE>GC3.8^ 

* ' « * ^ ' 

i29BDCC^t: 

•* .s . • 

: n ■ :. : -- J - 

l2^BDb078 

•"' ■' . 

i29Bb9B9& 
|29feDDd78' 
i29Bb9B90.'; 
^29BbbdTi8 
•2^BDCFB8 



j29BDeFB8- 
;29Bbb078 
!29BbB^^G 



Total = b, Writtai=b, Read=6 ' • 
Start = 0, Length=0, Max=512 . 
Accessot tef=5 

.Accessor ref =3 

■ * •-. * • 

Key=AiixOut Flags=aOOdQOOD " ; 

. Hpe t:ef=2 ; - " .V 
- tb^ = -i; >ill7iittea=0, R.ekdFd 
[ ; * Statt^#'0, I^^=0, Max=^512 
. : A5ccess6r^f€if==l .[ 

^ f : -'"1.: • 



Accessdrii:efr=2V' 



HKey=EttvIn FliS^(to0O0d03^ ; 



= Bundle ref=7:. >:" . 
/k^==EnvOutFl2ffi5=00b00067 
■■ :Bundle.:r(Bf=7 - . ^ ' ' 
Key=Param Fiags^F^ 
.Stririg;ref=3 ^ I i. 

; Key:=Identit^)FIags= ^ 

— — GomtDldted request-O' 
—End command 



. — CancelWritePipe 

i. ■ ■ • • . ■ 

I29BDC970 Object passed in 

■ *" " 

Linkt)bject ref=2 
. Flags = C,S,W, 



i29BDC970 



I29BDC970 
,29BDC970 



1 



I29BDC6A8 



I29BDC6A8 
i29BDC6A8 
29BDC90C 
!29BDC970 



PipeWritet ref=i 
Pipe ref=2 
Total = -1, Written=:2264, Read=2264 
Start =.0, Length=0, Max=512 

* « 

Accessor ref=l 

Accessor ref=l 
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Completed request 0 

f * • * 

: End command 

• Begin command 

!«: StopTask 

;29BDCFE4 Object passed in 
!29BDCFE4 IjnkObiecttef=l 
;29BDGM4- - . Hags = S,R,W, ' 
I29BDGM4 ^ v Task ref=2" 

t . ..• \ . . . • 

t..« 



r29BpCFE4 . • <. ilibraiy = ZrVSysfen^^ 



.-.•ti 



10 29BrjCEE4 = • Params. = relist 4 

1 • • --J • - , , - - • >^ ■ --. 

l29BI>eFE4:;i^ ^ ! -Stkte'^'TefTn Result ^ 0(00000000 • 

j Completed request 0;;^ / ; 

I — - Jr.— End command ^ 

f29BpGEiB4 :^estep^5r^;.sh2ie 
^2l)i^B)SgC Destroyed share \ 
^9KbC97byi;Destr6yedsW^^ 
l29Br)984<: Destroyed share . 
i29BDGG9G Destroyed share • 
^29BD9B90 Destroyed share'. ; 
20 j29BDCFB8 D^stiroyfed share \ 
29BDBB9C Destroyed sKafe:- - 
t2S)BE)E094 Destiroyek/share* 1 
|-~ — ^ Closing....:-., ; •"• • ■■ * 



25 

This is a LOT of debugging but contains a FULL dump of all the clients interaction with 
the kernel — it is more useful for debugg;ing the kemel but internally we might also use it 
when ^mr* libraries need debugging. 

30 7 MdxCUent.dU 

This class which exposes the client interface of the kemel is best described in a separate 
document aimed at users of mrix. It attempts to connect to the kemel , where necessary 
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starting it ( using MtixKemelLoader.exe on a device ) and dien provides various 
functions that the user can use to access a range or mrix functions. 
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